Uh oh!
There was an error while loading. Please reload this page.
Report an inert section visibleWhen on the tabbed and wizard arms (the ruled interim diagnostic) - #6733
Merged
Conversation
…nd wizard arms ObjectForm rebuilds each section key by key when delegating to a layout, so a key the map does not copy never reaches a renderer. The split/drawer/modal maps copy visibleWhen (#6111) and the flat arm carries it on the section-divider pseudo-field; the tabbed and wizard maps copy nothing, so an authored section predicate did nothing at all, with no signal anywhere. Those two arms now warn, naming the layout and the sections being dropped, through one shared message builder. No rendering behaviour changes and no authorable key is added: this is the interim half of the 2026-08-29 ruling that the real repair is one section/group predicate contract designed once for every layout arm. Deliberately silent on the four arms that honour the key, and on the master-detail branch, which re-enters ObjectForm where the real layout is decided. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CRJge11jso9TpXRWFt1Z49
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-sales
marked this pull request as ready for review
August 29, 2026 04:51
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #6237 — deliberately not
Fixes. This ships the ruled interim half only; the card stays open for the design task the same ruling created.The order's premise was dead, and that is the first finding
The dispatch order asked me to give the tabbed arm a
visibleWhenslot and make the renderer honour it. That already exists onorigin/main. It landed in #6619 (commit46f0bb4f5, 2026-08-27) and both halves are live:packages/types/src/form.ts—FormFieldTab(the arm the card's title names):packages/plugin-form/src/ModalForm.tsx— the sibling declaration it mirrors, onModalFormSectionConfig:The renderer evaluates it (
hiddenFieldTabKeysinrenderers/form/form.tsx) andModalForm's tabbed synthesis copies the section predicate onto the tab (visibleWhen: g.visibleWhen). Measured green onorigin/mainbefore touching anything: the existing pin suitefieldtab-visiblewhen-6237.test.tsxruns 12 passed (12), andsectionVisibleWhen-6111.test.tsx+zod-mirror-parity.test.tsrun 27 passed (27).Adding a second slot would have been a redundant declaration, so I did not.
On the zod mirror, which the order flagged:
FormFieldTabhas no zod counterpart at all —fieldTabsis not modelled inform.zod.ts(0 occurrences), and that absence is already ledgered as a pre-existing LOCAL divergence inzod-mirror-parity.test.ts('form.zod.ts#FormSchema': … | 'fieldTabs' | …). So there is no mirror asymmetry to close here, and adding a validated surface no ruling covers would have been unauthorised widening.What is actually broken, and what this PR does
ObjectFormrebuilds each section key by key when it delegates to a layout, so a key the map does not copy never reaches a renderer. Measured across all five routes:visibleWhen?formType: 'tabbed'→TabbedFormformType: 'wizard'→WizardFormformType: 'split'→SplitFormformType: 'drawer'→DrawerFormformType: 'modal'→ModalFormcontentLayout: 'tabbed'via #6619The
modalmap even carries a comment naming the hazard — "this mapping rebuilds each section key by key, so a key it doesn't copy is silently dropped" — which is why the two omissions read as omissions rather than as design.Per the maintainer ruling of 2026-08-29 (option A), making those two arms honour the predicate is a design task: one renderer-side section/group contract with a predicate slot, designed once for every layout arm, answering the three binding semantics (hidden-tab required fields, active-tab re-selection, collapse below two tabs). Ruled as part of that option, a loud diagnostic lands first. That is this PR:
sectionPredicateUnsupportedWarning, so the two arms cannot drift apart. It is not added to the package barrel — no published surface widens.useEffectinObjectFormreporting the gap, keyed on primitives so it fires once per mount rather than once per keystroke.routesToMasterDetailhoisted out of the existing branch condition and reused, so the diagnostic and the actual routing cannot disagree.No rendering behaviour changes. No authorable key is added anywhere — declaring
visibleWhenon a type whose renderer ignores it is the exact defect this card family exists to close, and theFormSectionConfigthatWizardFormshares for its steps makes that trap concrete.Declared scope call — please trim if unwanted
The ruling names "the tabbed arm"; I cover both silently-inert arms (
tabbedandwizard). Rationale: both drop the key through the identical mechanism, the docs support table already lists both as No, and covering the second costs one array entry and no new surface — whereas leaving it out keeps an author writing a wizard step predicate in exactly the silence the ruling set out to end. Trimming to tabbed-only is a one-line change if the maintainer prefers the literal reading.The pins, and their red-against-unfixed-source verification
New:
packages/plugin-form/src/__tests__/sectionPredicateLayoutDiagnostic-6237.test.tsx— 14 passed (14).It pins reporting, never behaviour — it must not grow an assertion that a tabbed or wizard section actually hides, since that is the design task's deliverable. The negative rows are the load-bearing half: a diagnostic that fires everywhere is as useless as one that fires nowhere.
Ablation (fix committed first, so the restore leg has a real reference). Mutation neutralised only the
console.warncall, leaving the builder and the routing guard intact.c6e97a309). Mutation proven on disk: anchor count1 → 0, injected count1, blobde30e381 → 191ed7f5.git diff HEADis empty.Docs
Both surfaces already carried a correct support table with
TabbedFormsections andWizardFormsteps as explicit No rows, so no prose was wrong. Each now also states that those two rows report themselves, with the message and the reason it is interim:content/docs/plugins/plugin-form.mdxandpackages/plugin-form/README.md.What stays open on #6237
The design task itself — the one grouping contract across all layout arms, and its three binding semantics. This PR does not touch them, which is why it is
Part ofand notFixes.Generated by Claude Code