feat(spec): FormSection.pane — explicit split-pane placement (objectui#2153 follow-up) - #4160
Merged
Conversation
…tui#2153 follow-up)
A `type: 'split'` form view had no way to say which pane a section renders in:
the renderer hardcoded "first section left, everything else right". That
positional rule is invisible in the metadata, so reordering sections silently
moved them across the divider, and an author (human or AI) could not place two
sections on the left at all.
FormSectionSchema gains an optional `pane: 'primary' | 'secondary'`:
- explicit and PER SECTION, so placement survives reordering and an agent
editing the view can see — and must preserve — where each section lives;
- omitted → the legacy positional rule (first section primary, others
secondary), so keyless metadata keeps its exact layout;
- split-only, enforced loudly: a FormViewSchema refinement rejects `pane` on
any other form type at parse (legacy `groups` alias and defaulted
`type: 'simple'` included). "Accepted but ignored" is the failure mode this
key must never have — a silent no-op reads as working, especially to an AI
author. Verified that zod 4 keeps refinements through `.extend()`, so the
flattened runtime-overlay variant in ViewMetadataSchema enforces it too;
- strict two-value enum — a typo ('left') is a parse error, not free text.
The 'split' enum comment claimed "Master-Detail split"; master-detail already
has two homes (`subforms` on the form, related lists on record pages), so the
comment now states split's non-redundant meaning: side-by-side resizable panes
with sections placed via `section.pane`.
The showcase task form's `split` view declared a single section — which renders
as a plain, unsplit form — and now demonstrates the feature: two sections with
explicit panes. `authorable-surface.json` regenerated (one new entry).
Renderer support ships in ObjectUI (SplitForm → FormSchema.fieldPanes, whose
pane keys are already named primary/secondary — a 1:1 mapping).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 106 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
check:docs gates generated reference docs against the spec; the new key needs its generated row committed alongside the schema change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
59 tasks
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
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.
Why
A
type: 'split'form view has no way to say which pane a section renders in — the ObjectUI renderer hardcodes first section left, everything else right. Evaluated against two criteria (platform long-term soundness, AI-authoring error avoidance):'split'enum comment claimed "Master-Detail split" — but master-detail already has two homes (subformson the form, related lists on record pages). A third would be redundant vocabulary (another AI-error source: three dialects for one intent). Split's only non-redundant meaning is the side-by-side section layout, so the comment now says that.What
FormSectionSchema.pane: 'primary' | 'secondary'(optional):primary, restsecondary) — keyless metadata keeps its exact layout, zero migration.FormViewSchemarefinement rejectspaneon any other form type at parse — covering the legacygroupsalias and the defaultedtype: 'simple'. "Accepted but ignored" is the one failure mode this key must never have. Probed zod 4.4.3 before relying on it:.extend()keeps refinements, so the flattened runtime-overlay variant inViewMetadataSchema(view.zod.ts:1491) enforces it too.pane: 'left'is a parse error, not free text; orientation-neutral names survivesplitDirection: 'vertical'and map 1:1 onto ObjectUI's already-shippedfieldPaneskeys (primary/secondary, objectui#3012).Also: the showcase task
splitview declared a single section — which renders as a plain, unsplit form, i.e. the demo never demonstrated the feature — and now has two sections with explicit panes.authorable-surface.jsonregenerated (exactly one new entry:ui/FormSection:pane).Verification
view.test.ts: accepts panes on split (omitted staysundefined), rejects typo values, rejectspaneon non-split with a pointed message atsections.1.pane, same for thegroupsalias, and defaulted-typecounts as non-split.@objectstack/spec: 273 files / 7124 tests green; build green (incl. the Studio JSON-schema derivation path).@objectstack/example-showcase: 60/60 green after building its dep graph — the updated config round-trips the full Zod parse (gap-fillimportsobjectstack.config.js).Follow-up (ObjectUI)
SplitFormmaps sections →FormSchema.fieldPanesby the hardcoded slice today; the follow-up PR readssection.panewith the same positional default. No compile-time dependency on this spec version (the key arrives as plain JSON), but this PR merges first per cross-repo convention.🤖 Generated with Claude Code