Skip to content

[finding] object-master-detail-form declares formType as a bare string while the renderer switches on the object-form variant enum — an out-of-vocabulary value silently routes around the whole simple-form path #5939

Description

@os-warren

Found while resolving #3840 (fixture-vs-product fork on the binding-reach probe). Not fixed there — #3840's scope was the probe fixture, and this is a declaration shape. Observation-class: filing for triage, not queueing.

Fact (objectui origin/main @ 2074a59)

packages/plugin-form/src/index.tsx declares the two form blocks' formType differently:

// object-form{name: 'formType',type: 'enum',label: 'Form Type',enum: ['simple','tabbed','wizard','split','drawer','modal']},// object-master-detail-form{name: 'formType',type: 'string',label: 'Parent Form Presentation',description: 'How the PARENT half of the form is presented. …'},

@objectstack/spec agrees with the loose one: ObjectMasterDetailFormPropsSchema.formType.safeParse('x') returns success, where ObjectFormPropsSchema.formType.safeParse('x')rejects (its options are exactly the six above).

But both blocks funnel into the same renderer, which switches on those six names — ObjectForm.tsx:1134 gates the simple/sections path on:

if(effectiveSections?.length&&(!schema.formType||schema.formType==='simple')){

with 'tabbed' / 'wizard' / 'split' / 'drawer' / 'modal' handled at :236 / :260 / :287 / :325 / :355.

Why it matters

A formType outside that vocabulary is not rejected anywhere and does not render anything specific — it silently matches no branch, so the parent half falls through to the flat field list with no diagnostic. An author who typos 'wizzard' gets a plausible-looking form and no signal.

Measured consequence, and the reason this is worth a card rather than a shrug: it hid a real crash for as long as anyone had looked. In the #3840 probe the generic sample for a string input is 'x', so object-master-detail-form skipped the section loop entirely and read green, while object-form (whose enum sample is 'simple') painted an error card on the identical malformed input. Forcing formType: 'simple' on the master-detail block reproduced the same Cannot read properties of undefined (reading 'map'). A value outside a prop's vocabulary routes around the block instead of exercising it.

Triage question

Whether the fix is to tighten the declaration (and the spec's ObjectMasterDetailFormPropsSchema) to the shared enum, or to have the renderer reject/report an unknown formType rather than falling through, or both. Note the enum is the narrower claim and the contract-first one — the declaration is what an authoring UI and publish-time validation read.

Related: #3840 (where this surfaced), #3838.

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:devxobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repofinding

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions