[AlexSamBY]

A table row that a useForm declaration gives a form of its own now starts with its values, and a submit sends every row with its edits. The merge a showIf reads is made once per change of the forms instead of once per node, which takes the square out of a mount of such rows.

The defect

A row's form started from the row's values at the root of its own values, while its fields are named by the row's place (dataKind.items[1].kind, mapper.tsx) and read them there. Measured on master (8e76778), React 18.3:

• every field of such a row started empty;
• a submit after an edit of the second of three rows sent the first two, the second without its edit: the live merge (getLiveMergedDataKindArray) capped the rows at the row form's array, which reaches only as far as its own row, and the document's copy, merged after the row form's, took the edit back;
• a notWithinRange check in such a row read neither end of a period the user had not typed there, so typing a start date that overlaps another row showed nothing;
• new rows a host handed over showed empty too.

The published 0.34.3 bundle does the first two as well, measured under React 18: this is no regression of 0.35.0. EPBDS-17018 is the defect's ticket, and this covers its acceptance criteria. #241 measured the first two, and EPBDS-13465 mentioned them as backlog. No known host config uses useForm rows.

The fix

• engine/Data.tsx: a useForm row's form starts from the row's values placed at its place, with final-form's setIn, so the containers are the ones final-form writes the row's fields into (dataKind.phases.0.dataKind.lines[1] makes phases an array). A table's add row (draftRow) starts from what its meta declares, as before, and so does a row that holds no object (see the review below).
• engine/formData.ts: rowPlaceOf(meta) names a row form's place, for both merges. Both merges take from a row form the values of the fields it changed, and nothing else: each field whose value is not the one the form started with (changedInside) is read in the form's values by its name and written at that name over the documents' copy of the row, as final-form writes a field's value (writeField, with final-form's setIn). The form's start is its initialValues, moved field by field to what the forms holding the document from its root hold of its values after a submit (restartWrittenRows, kept on the engine's side, for the initialValues the form had): the document holds them from then on, so an edit set back after a submit is a change. The rest of the row stays as the documents have it, a field the row's cells only show included, which another form may have edited. A value the form no longer holds takes that value away, and each object it leaves empty but the row, as final-form does. A field that holds an array, as a table's does (FieldArray), is written whole. The live merge counts a row form in no cap, so the rows after an edited row stay, and leaves out a row past the documents' rows (one just removed). It takes the fields of a row with a form of its own inside one of its rows too, such as a useForm line of a table in a row's expanded content: a submit writes only the top arrays back, as the live merge gives them. Both write the rows shallowest first, so a row with a form of its own inside another such row writes after it. A row form's values hold a sparse array up to its index, which nothing copies.
• engine/rules.tsx: submit calls restartWrittenRows as it writes, before final-form validates: a submit that validation stops has written all the same. A start moves only to what the forms holding the document from its root hold, so a submit that a row's own document makes, from a button in the row's cells or a field there with autoSubmit, which writes into the row's form, moves none.
• modules/form/batchedForm.ts: a form names every field it has registered (fieldNamesOf), the ones that have gone included: final-form keeps the value of a field a showIf hides, and the document's form keeps its copy, so the merges keep the edit, as they did when they took a row form's whole values. react-final-form's probe in a field's first render gives no name: the field registers again from its effect.

Found in review

The first version took a row form's whole row in both merges. Its form starts from the whole row, so the row as it started came back over an edit another form had made of it. Each scenario below was confirmed by a test, and none was in 0.35.0:

• A field in the row's expanded content, which the document's form holds: getFormData, a submit and a showIf read the row's value as it started, and so did upload and Apply, which read what getFormData reads.
• A table in the row's expanded content: an edit of its rows was lost in the same places, and a showIf in one of them read the row as it started.
• A period table there: the cross-row check compared the edited row with the copy in the row's form and found no overlap.
• An empty (null) row: the Data view is handed the document's data for it (mapper.tsx), which the form put at the row. getFormData and a submit had a copy of the whole document as the row, and a field of the row showed a value the document holds under its name.

The merges then took what a row form changed of the row it started from (changesOf, replaced since: see the third review), and a row that holds no object is not placed: its form starts as it did in 0.35.0.

A second review, at 03f9bfd, found three more, each confirmed by a test. Two are fixed here, and the third is in Not in this change:

• A value cleared in a row's cell: final-form drops a value set to undefined, as a field with normalize: 'date' sets it for an empty date, and changesOf saw no change in a value no longer held. The document's copy showed the date again in getFormData, a submit and a showIf. Such a value is now the value of a field the form no longer holds, which the merges take away.
• A Data view rendered without a document instance, as a cell of a table's extraItems, a tooltip's children, an input's icon and a values renderer render it, threw as it read the instance's data. 0.35.0 rendered it. It reads that only for a useForm row now.

A third review, at 274593f, found three more in changesOf, each confirmed by a test for useForm rows, which rows sharing the document's form passed. So the merges no longer compare a row form with the row it started from: they take the values of its fields (see The fix).

• A field named length: changesOf marked an array made shorter by a step named length, so an edit of such a field never reached getFormData, a showIf or a submit. 0.35.0 had it in the first two.
• A nested field in a cell, address.city, beside address.zip in the expanded content, where the row had no address: the row form's address, which the row did not start with, was written whole, and the zip was gone from getFormData, where 0.35.0 had both, and from a submit.
• A nested date cleared in a cell, period.start, beside period.end in the expanded content: final-form drops the emptied period from the row's form, changesOf gave all of period as removed, and the end went with it.

A fourth review, at 11424bc, found two more, each confirmed by a test:

• A field the row's cells show, which another form of the document holds too, such as the row's expanded content's: the row form wrote the value it started with, never edited, over that form's edit, in getFormData, a showIf and a submit, and the submit wrote it back into the expanded content's input. The same for a read-only field in the cells, and for one a showIf there had shown and hidden. Rows sharing the document's form had it right, and so did 0.35.0. A row form now gives only the fields whose value is not the one it started with (changedInside): the third review's cases stay fixed, and so does the edit of a field a showIf hid.
• A submit writes only the top arrays back, as the live merge gives them, and that merge left out a row with a form of its own inside another table's row: the edit of a useForm line in a phase's expanded content reached getFormData, and not a submit, whether the phases had forms of their own or not. Measured the same on master. The follow-up's session found it.

A fifth review, at 5ffe189, found one more, confirmed by a test: an edit of a useForm row set back after a submit. The submit writes the merged rows into the document's form, in place, before final-form validates, so the document holds the row's edit from then on, and the row's form, measuring from its initialValues, took the value set back for no change: the document's copy brought the edit back in getFormData, a showIf and the next submit. The same for a useForm line in a phase's expanded content, and after a submit that validation stopped (measured: nothing was sent, and the edit came back). Rows sharing the document's form had it right; 0.35.0 sent no edit of such a row at all. The submit now moves the form's start to what it wrote (see The fix), which leaves the form's own state, pristine and touched, alone.

A sixth review, at a4de519, found one more, confirmed by a test: a submit made in a useForm row's cells, by a Save button there or by a field there with autoSubmit {delay: 0}. It submits the row's own document, whose submit writes the merged table into the row's form, not the document's, and the rows' starts moved to what that form held: every edited row's edit became its start and gave nothing, while the document's form held none of them. getFormData and the document's submit dropped the edits of every row, though the cells showed them. Rows sharing the document's form had it right. A start now moves only to what the forms holding the document from its root hold, whichever form submitted; what a row's own submit writes into its form is left as it was.

The cost

Every node whose showIf reads the form decides by every form of its document merged (getRawFormsData), and each node merged them as it decided. The first version of the fix also wrote every row form's whole row over the document's copy in every merge, and a mount of 200 useForm rows took about a third longer in jsdom (650 to 870 ms). The profile put almost all of the mount in getRawFormsData, which a mount ran 4n times.

So the merge is now kept per document tree while what the page's forms hold stays the same (engine/keptRawFormsData.ts):

• formsStorage counts each form that registers, goes or registers again (formsChangeCount). A form that new initial values reset registers again with the meta of the render that brought them, which no values tell.
• createBatchedForm wraps subscribe: the first values subscriber told of new values counts them before it hears of them. The tree's tells (A showIf that reads a field of a useForm block follows it #249) are too late for this: the form layer subscribes for them as the form commits, after the nodes under it, and a node in a List that follows its own form decided by the previous merge (showif-follows-form.test.js caught it). The count starts at the form's values when it is made, so react-final-form's subscription in its first render counts nothing.
• The submit action writes the live rows into the form's values in place, which final-form tells nobody of: it counts that change itself.
• A name that comes to a row's form, as when a showIf in its cells shows a field, can change what a merge writes but no form's values. createBatchedForm counts names on their own (fieldNamesCount). Where names came, the kept merge is checked against their values in the row forms (holdsFields): a name whose value its form did not change writes nothing, and one it changed must hold what the merge holds, or the forms are merged again. Counted as a change of what the forms hold, it merged once more at every mount, which the budgets caught: the mount's second merge comes as its nodes commit, before their fields register. The live merge compares each row form's names with those it merged by.

Counted with jest.mock around getRawFormsData, master against this branch, React 18.3:

	master	branch
mount, 20 / 40 / 80 useForm rows: merges	80 / 160 / 320	2 / 2 / 2
the same: forms merged	1260 / 4920 / 19440	21 / 41 / 81
mount, 20 / 40 / 80 rows sharing the form: merges	60 / 120 / 240	2 / 2 / 2
keystroke in those rows: merges, each a copy of the table	20 / 40 / 80	1 / 1 / 1

A mount of 200 useForm rows took about 660 ms on master and about 150 ms on this branch, in jsdom (median of 5 after 2 warm-ups, three interleaved rounds, Node 24.14); with the review's fix, about 140 ms, measured later in the same sitting. Measured again on another day, with three interleaved rounds each: master 676 to 801 ms, 274593f 160 to 180 ms, 11424bc 162 to 179 ms; later that day, 11424bc 145 to 151 ms and 5ffe189 145 to 148 ms. The table's counts were measured again at 11424bc, at 5ffe189, at a4de519 and at 248f0ad, and are the same.

What a showIf decides is unchanged, and so is how often: a useForm row's cell still decides once more at mount than it renders (80 on React 18.3, 60 on the others), now a lookup.

Tests

• rules.row-form-values.test.js: the fields start with the row's values, a submit after an edit sends every row with the edit, a host's new rows show and a showIf reads them, and a period overlap with another row shows. All four fail on master.
• rules.row-form-values.test.js, the review's scenarios: an edit in the row's expanded content, in a table there and in a period table there, and an empty row. All eight fail on c95fbd5. On master all pass but one, which edits the row's own field as well.
• rules.row-form-values.test.js, the second review's: a date cleared in a row's cell, and a useForm block in an extraItems cell, which fail on 03f9bfd; a text emptied and a toggle turned off, and an edit in a null and in a {} row, which pass there.
• rules.row-form-values.test.js, the third review's, each for useForm rows and for rows sharing the document's form: a field named length, a nested field beside one the expanded content adds, and a nested date cleared beside a field the expanded content holds, which fail on 274593f with useForm rows; and the edit of a field a showIf in the cells then hides, which fails when the merges read only the fields registered at the time, as a mutation showed.
• rules.row-form-values.test.js, the fourth review's: an edit the expanded content makes of a field the cells show, in an input and in a read-only one, and of one the cells showed and hid, for both kinds of rows, which fail on 11424bc with useForm rows; the edits of a phase and of a useForm line in its expanded content, for phases with forms of their own and without, which fail on 11424bc and on master.
• rules.row-form-values.test.js, the fifth review's, for both kinds of rows: an edit set back after a submit, which getFormData, a showIf and the next submit read, and after a submit that validation stopped; a useForm line's set back after a submit, in a phase's expanded content. They fail on 5ffe189 with useForm rows and lines.
• rules.row-form-values.test.js, the sixth review's, for both kinds of rows: a submit made by a Save button in a row's cells, after edits of two rows, keeps them in getFormData and the document's submit; an edit set back after it reads as set back; a field with autoSubmit in the cells keeps the rows' edits in getFormData. The first and the last fail on a4de519 with useForm rows.
• formData.test.js, restartWrittenRows: no start moves where the forms that hold the document from its root do not hold the row's values, or where there is no such form; what the document's form holds of a row's changes becomes its start, so a change set back is one more, and the check of a kept merge reads it; a field the document's form does not hold keeps its start; a value taken away there becomes a start with none; new initial values start the form anew; the live merge merges again once a start moved.
• formData.test.js: what the merges take from a row form, the values of the fields it changed: over a document another form edited, a field it shows and leaves alone left out, a value no longer held taken away with an object it leaves empty but the row, a field named length, a field written into an object another form gave a field of its own, a hidden field's value kept, a field the document's copy has no room for left out, a field that holds an array taken as the rows, a row form inside another written after it; the live merge's row branches, a row with a form of its own inside one of its rows among them, and its cache, which merges again once a row form has a field it had not, or starts from other values; rowPlaceOf; holdsFields, which holds for a name the form did not change.
• keptRawFormsData.test.js: one merge while the forms hold the same; a new one after new values, after a registration with no values told, per tree. A field that comes to a row's form with no new values keeps the merge where the merge holds its value, and where the form did not change it; merges again where the form changed it to another value than the merge holds, at once inside a bracket too; one that comes to a document's form keeps it.
• batchedForm.test.js: new values are counted once, before the first subscriber hears of them; nothing is counted for other subscribers or unchanged values. A form names every field registered from an effect, in order, the ones that went included, and none for react-final-form's probe; the same list until a name comes; a name counted as no change of what the forms hold; a copy's names are the form's.
• formRegistry.test.js: the storage counts set, delete and clear.
• kept-show-if-budget.test.js pins the merges (mount 2, keystroke 1, on React 16.14, 17.0.2, 18.3 and 19.3); later-mount-budget.test.js lowers two counts that fell (1330 to 1126, 3230 to 2826, 822 to 820; 21322 to 21320 on React 16). No budget number rises.

Not in this change

• Removing a row with removeData still loses what was typed in the rows after it: the removal reads only the document's form (removeDataKindRow), and the rows below move up and start again from the document's copy. Measured the same on master.
• Edits in the cells of a useForm row are reset when an Add or a Remove rebuilds the document's data so that the row's data changes: a line added to or removed from a table in the row's expanded content, or an Add after an edit in the row's expanded content. pushDataKindRow and removeDataKindRow write a clone of the document form's values, which hold none of a row form's edits, and WithForm resets the row's form to its new initial values, as it does for a host's new data. 0.35.0 resets these forms the same way, their fields empty from the start. Rows sharing the document's form keep their edits. Found in the second review.

A separate PR will close both: it writes the row forms' changes into the document's form before a row is added or removed, and moves their start as a submit does (restartWrittenRows). The changelog says what an Add or a Remove still loses.

• A table in a row's cells binds its rows' fields outside the row: they are named dataKind.lines[0].sku, not by the row's place. Measured on master: in rows sharing the document's form its inputs are empty, and its removeData throws; in a useForm row its inputs showed the row's lines, which the defect put at the root of the row's form, but an edit or a removal there never reached getFormData or a submit. With this change its inputs are empty in a useForm row too, and a removal there clears the whole table on screen, where master removed one line; the data changes in neither. The array such a table registers (FieldArray) is named by the row's place, and the merges take it whole, as any field that holds an array.

Gates

On Node 24.14.0, at 248f0ad, each exits 0.

• lint:js, lint:css, typecheck, typecheck:contract, docs:views:check, docs:props:check, docs:phrases:check, css:fixture:check, build-css:check, sync-version -- --check;
• npm test and test:react16, test:react17, test:react19 (254 suites, 3429 tests each; one suite skipped on 16 and 17, as designed), and test:coverage with every threshold held (formData.ts 100% of statements and functions and 99.45% of branches, keptRawFormsData.ts 100%);
• build-lib, test:css:built, test:types:consumer, test:pack:budget, test:pack:consumer, test:pack:peers, test:env-flags, build;
• CI=1 test:e2e and CI=1 test:e2e:react19 (77 each), test:pack:browser and test:pack:browser:peers.

The first run of test:react16 lost two jest workers to a SIGSEGV (nodejs/node#62393) in validateMeta.contract.test.js and InputNumber.test.js, with no test failing; run again, it exited 0. No budget number rises: kept-show-if-budget.test.js and later-mount-budget.test.js pass unchanged. The jest legs ran with <rootDir>/\.claude/ ignored as well, for a stray, gitignored probe in this checkout, and without the review's scratch tests, which are not committed. Those ran on their own on React 16.14, 17.0.2, 18.3 and 19.3: 119 of 122 (251g 14 of 14) pass on each, and the three that fail are the Add and Remove cases of Not in this change. Every hit of both caches was compared with a fresh merge through a temporary check, not committed, across the whole suite, the review's scratch tests included, on React 16.14, 17.0.2, 18.3 and 19.3: none differed. Not run here: test:e2e:engines, test:perf and audit:bundled, which CI runs as advisory or weekly jobs; this change adds no dependency.

🤖 Generated with Claude Code