Core consideration¶
This section evaluates Form Factory Kits against an open Drupal core discussion about object-oriented form building. It is written by this module's side and is meant as input to that discussion, not a verdict on it. Corrections and disagreement are welcome in the issues linked below.
The core issue¶
#3525331 "Reuse Element Plugins as Object Wrappers Around Render Arrays" proposed using core's element plugins as objects that wrap render arrays. Its public timeline, as shown on the issue page (fetched 25 October 2026):
| Date | Event |
|---|---|
| 19 May 2025 | Issue opened. |
| 27 June 2025 | Committed to 11.x, with change records. |
| 12 August 2025 | Reverted, because of AJAX failures tracked in #3539320 "Element plugin object wrappers causing AJAX failures". |
| 22 November 2025 | Form Factory Kits suggested in the thread by this module's maintainer (comment #84). |
| 12 December 2025 | Comment #91 suggests evaluating the Form Factory Kits approach first. |
| 6 March 2026 | Comment #95 lists four open questions. |
On 25 October 2026 the issue status was Needs work, comment_count was
95, and the issue's changed time was 6 March 2026, so comment #95 was
still the latest comment. Read the issue itself for anything newer; this
page will go out of date.
On the module side, #3562924 "Drupal Core Merge Consideration" tracks preparing Form Factory Kits for possible inclusion in core. It lists "90%+ Test Coverage" and an "Alpha release" as remaining tasks.
Three options¶
The pages in this section compare three ways of building forms:
- A: bare render arrays, what Drupal does today. Any object layer costs more than plain arrays, so A is the baseline, not a competitor.
- B: element-plugin object wrappers, the approach in #3525331.
- C: Form Factory Kits, this module.
The comparison that matters is B against C. B was measured for real, by applying the issue's merge request to a copy of Drupal core (see Benchmarks).
Why this section exists¶
Comment #95 says its author had not looked at Form Factory Kits and that "perhaps it deserves a separate issue to look at it". The pages below collect the evidence such a look would need, so reviewers do not have to reconstruct it:
- Findings: the 25 October 2026 check of #3562924's remaining tasks, and which sentences on the pages below are no longer true.
- Concerns: the four questions from comment #95, each answered with pointers to code in this repository.
- Comparison: A, B and C side by side, including what wrappers can do that kits cannot and the reverse.
- Benchmarks: measured memory and time for A, B and C on a 500-field and a 5,000-field form, plus the array → object → array round trip that only wrappers can do.
- Runtime cost: whether kits are suitable at runtime given their higher build-time peak, and untested ideas for reducing it.
- Readiness: what is done and what is still open before a core proposal would be credible.
- Merge path: the options for getting there and what each would cost.
The short version: compared with wrappers, kits keep the render array plain (no objects or references left in it) and retain about 38% less memory, at about 18% higher peak memory while building (28 October 2026 run; build time was lower than wrappers on the 500-field form and within noise on the 5,000-field form). Wrappers can do one important thing kits cannot: open an existing array and edit it as objects. The kits code is not ready for core yet. Test coverage is incomplete, the dependency chain is in beta, and the readiness page lists several bugs found while writing these docs.