fix(form): a tabbed/split form honours the form view's own columns - #3018
Merged
Conversation
FormView.columns is a spec key (view.zod), but only ObjectForm's simple path and
ModalForm read it. TabbedForm and SplitForm derived the grid width from the
per-section `columns` alone, so a view declaring `columns: 3` rendered 3 columns
in a modal and single-column as a tab or split — the same metadata laying out
differently depending on which host picked it up.
Both now resolve the grid the way the other hosts already did:
explicit form `columns` ?? widest section's `columns` ?? 1
The two keys answer different questions and the precedence reflects that: the
view's `columns` is how wide the grid is, a section's `columns` is how densely
that section fills it (via per-field colSpan). `columns` is declared on
TabbedFormSchema / SplitFormSchema accordingly — ObjectForm already spread it
through, it was simply being dropped on arrival.
WizardForm is the remaining host that ignores it; left out deliberately, since a
wizard's grid is per-STEP and needs the density/width split introduced properly
rather than a one-line precedence swap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
github-actions
Bot
added
documentation
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #3012, where this inconsistency surfaced.
The gap
FormView.columnsis a spec key —view.zoddeclares it right next tosplitDirection/splitSize. But onlyObjectForm's simple path (ObjectForm.tsx:914) andModalFormactually read it.TabbedFormandSplitFormderived the grid width from the per-sectioncolumnsalone:So a form view declaring
columns: 3rendered 3 columns in a modal and single-column as a tab or a split — one piece of metadata laying out differently depending on which host picked it up.ObjectFormwas already spreadingcolumnsthrough to both; it was simply dropped on arrival, so nothing downstream could tell the key had been authored.Per AGENTS.md #0 this is a compliance bug, not a preference: the renderer was silently discarding a declared spec key.
The fix
Both hosts now resolve the grid the way the others already did:
The precedence reflects that the two keys answer different questions — the view's
columnsis how wide the grid is; a section'scolumnsis how densely that section fills it (via per-fieldcolSpan).columnsis declared onTabbedFormSchema/SplitFormSchemaaccordingly.Tests
Three cases added to
packages/plugin-form/src/sectionColumns.test.tsx(the existing home for grouped-section layout), verified failing first — both host tests failedexpected null not to be nullon the 3-column grid class, while the section-fallback case passed, confirming the baseline was precisely "view columns ignored, section columns fine":TabbedFormhonours the view'scolumnsSplitFormhonours the view'scolumns38 files / 293 tests green across
plugin-form+ the form renderer;turbo type-check12/12; lint 0 errors.Deliberately out of scope
WizardFormis the remaining host that ignores view-levelcolumns(WizardForm.tsx:531 passes onlycurrentSection.columns || 1). Left out on purpose: a wizard's grid is per-step, andsectionFormLayout(fields, cols)currently collapses width and density into one number — honouring the view key there means introducing the width/density split properly (applyAutoColSpan(body, formColumns, section.columns)+containerGridColsFor), which also changes the default width of every existing wizard step. That deserves its own PR rather than being smuggled into a precedence swap. Happy to do it next.No browser verification for this one — the change is a resolved integer feeding existing, already-verified grid classes, and the three DOM assertions cover it.
🤖 Generated with Claude Code