EPBDS-16211: fields that mount after the first render no longer tell each other of themselves one by one

[AlexSamBY]

What

#219 made the first render's fields register in one pass, while react-final-form holds validation back. Fields that mount later still registered one at a time while validation ran: a tab switch, a showIf that flips, a popup that opens, a row that expands, a table page. Each registration published every field's state and, with a validator, validated every field. Each field that went did the same. A burst of n fields therefore cost about n²/2 of each, both ways.

registrationsOf(form) (src/core/modules/form/batchedForm.ts) gives an engine node brackets around such a burst:

1. RenderComponent (src/core/engine/mapper.tsx) opens them in a layout effect, and closes them in a passive effect.
2. It does so on mount, and when its showIf flips.
3. Fields register in passive effects, between the two, so they register while validation is paused:
   • silently, as on the first render;
   • and a field that goes holds back what it would tell.
4. The outermost bracket pauses validation and resumes it once, which validates and tells every field once.

Brackets nest, and the outermost one pauses only when nothing else has: on the first render, react-final-form's own pause does the job, as before.

Why every node, and why effects. A field joins the form wherever a swap point puts it: Tabs, ProgressSteps, Expand, a table's row expansion or page, Modal, a showIf, or rows from data. Each swap point lives in its own component, with its own state. But every engine node on either side of a swap is a RenderComponent.

• A new subtree's root node opens its bracket in the layout phase. That is after the commit's DOM changes, and before any passive effect runs.
• It closes the bracket in its passive effect. That comes after its children's registrations.
• On React 17 and later, it also comes after the old subtree's passive cleanups, which run first. So a tab switch brackets both the new content's fields and the old content's.

The bracket closes synchronously, in the same flush as the registrations. A microtask would have closed it after act returned, and its notifications would then reach React outside act.

A submit inside a bracket, between a commit and its passive effects, validates what has registered so far before it submits.

Measured

In Chromium

npm run test:perf --tarball on the packed master and on this branch. Eight interleaved rounds on an Apple M4, load average 2.1 to 4.6. The median of the eight rounds' medians, with their range:

document / action	master	this branch
two tabs: a switch to the 200-row table	241 [225–247]	78 [70–82]
two tabs: a switch back	232 [228–238]	39 [36–41]
200-row period table: mount	234 [227–262]	240 [232–258]
200-row period table: first blur	38 [36–42]	42 [39–46]
every other mount and action		within 3 ms of master

The period table's mount may cost a few milliseconds more: it has the most nodes, and each now runs two effects as it mounts. Its ranges overlap.

In jsdom: src/library/__tests__/later-mount-budget.test.js

The test uses a 50-row table of two fields per row: 101 fields. It counts the field states final-form computes, and the validators it runs, on every React leg.

action	master: states / validators	this branch
a switch to its tab	21008 / 5252	1212 / 202
a switch away	20200 / 5050	0 / 0
a showIf that shows it	21524 / 5252	1431 / 202
a showIf that hides it	21322 / 5151	822 / 101

Notes on the numbers:

• Hiding validates each field once. That comes from the form.change that hides it: a field changed with no validateFields validates them all.
• Registering later validates each field twice. One pass is the bracket's. The other is react-final-form's probe in each field's first render, before any bracket opens. It validates once per field here, since nothing else is registered.
• On master's code, the test fails.
• On React 16, the two removals cost what they did on master. React 16 runs a removed component's effect cleanups during the commit, before any layout effect, so no bracket is open. Fields that mount are bracketed there too.

Behaviour

batchedForm.document.test.js gains two cases, both on what the form's listeners hear:

• a tab switch that brings an empty required field: they hear the form is not valid;
• a showIf that shows such a field and hides it again: they hear not valid, then valid.

batchedForm.test.js gains the brackets' own cases:

• what registers between them is silent, and validated once;
• what goes between them is told once;
• they nest, and the outermost one closes;
• they leave a pause something else made to whatever made it;
• an extra close is ignored;
• a submit between them validates first;
• registrationsOf returns the same brackets for the copies of a form that react-final-form hands out.

batchedForm.ts is covered fully.

What this does not cover

• Fields that go on their own still go one by one: nothing mounts with them, and no showIf flips. That is a closed popup, an Expand collapsed, a row removed. On React 16, every field that goes does.
• react-final-form's first-render probe validates the whole form once per new field with a validator. It runs in render, before any bracket can open. In a form that already holds m fields, a later burst of n fields still runs about n × m validators through it. Pausing validation in render is not safe: a render React throws away would leave the form paused.

The perf check

• A new document: tabs, two tabs whose second holds the 200-row table, with a switch to it and back, five runs each. A switch waits for the table's field to be there, and a switch back for it to be gone.
• Ceilings follow the runner now. GitHub's runner took about three times as long as an Apple M4 to mount a document, and the M4 measured one build about twice as long on 2026-10-12 as on 2026-10-13. The ceilings are now two and a half to three times what the runner measured in EPBDS-16211: a document's fields no longer tell each other of themselves one by one as it mounts #219's run, and at least 100 ms for an action.
• Lowered: the Select-column and number tables' mount ceilings, to 820 and 780 ms, against 271 and 258 ms on the runner. They were set above 4 times.
• The tabs document's ceilings (330, 720 and 360 ms) are estimated from the M4's numbers at that ratio. This PR's own browser-perf run is the runner's first measure of it.

The plan's F4 item adds later-mount-budget.test.js to what the form-stack bump must run.

Gates

All 22 gates and the manifest contract exit 0 on HEAD, on Node 24.14.0, and so does test:perf. HEAD's own build measured a switch to the table's tab at 71 ms, and one back at 36 ms.

test:react16 exited 1 on its first run, because two jest workers died of SIGSEGV: the Node 24 crash of nodejs/node#62393. Every test that ran passed. Its rerun exits 0.

Tests.

• The suite has 2901 tests, 13 of them new. All pass on React 18 and 19.
• On React 16.14 and 17, 2897 pass and EPBDS-16211: contracts for a document inside a transition, and for what one edit costs in a 50-row table #207's 4 transition tests are skipped, as before.
• In the browser, the demo's 62 tests pass in Chromium on React 18 and 19, and so do the packed tarball's on React 16.14 to 19.

🤖 Generated with Claude Code