finding(fields): FieldEditWidget still drops the DECLARED non-DOM host-plumbing keys — `error`, `dataSource`, `dependentValues`, `dependsOn`, `dependsOnLabels`, `emptyHint`, `onUploadingChange`, `onSelectRecord`, `onCreateNew`

[os-sam]

Found while implementing objectui#6909 (the DOM pass-through half). Filed rather than folded in, because it is the same SHAPE but not the same fix — see "Why not folded in" below.

What

packages/fields/src/FieldEditWidget.tsx takes FieldWidgetComponentProps, which declares three groups of keys:

1. the controlled-input contract — value, onChange, field, readonly, disabled, className, error, onUploadingChange;
2. host plumbing — dataSource, dependentValues, dependsOn, dependsOnLabels, emptyHint, compact, onSelectRecord, onCreateNew;
3. the DOM pass-through block (FieldWidgetDomProps + AriaAttributes + the open data- family).

objectui#6909 closes group 3 (and, via the shared toDomProps whitelist, className / disabled). Group 2 and the remaining group-1 keys are still dropped: a host may pass any of error, dataSource, dependentValues, dependsOn, dependsOnLabels, emptyHint, onUploadingChange, onSelectRecord, onCreateNew to this factory with no type error, and the widget never receives it.

That is the same first-class class named in packages/fields/src/widgets/toDomProps.ts — "a key that type-checks, reads as supported, and silently never reaches the element" (objectui#3290's aria-required, objectui#3222's validation slot).

Measured on the branch for objectui#6909, at the factory boundary: the props object the factory hands the widget contains exactly field, value, onChange, readonly, the toDomProps whitelist, and compact for the three relational types. Nothing from group 2.

Why not folded into the objectui#6909 PR

That card's ruling was direction 1 — forward the DECLARED DOM block — and its fix is mechanical: reuse the package's own executor, which is already compile-time bound to FieldWidgetDomProps in both directions. There is no equivalent executor for group 2, and each key carries a real design question rather than a mechanical answer:

• error drives aria-invalid on the control. Its documented PRODUCER is the form renderer, from react-hook-form's fieldState. An inline-edit host has no react-hook-form state — so is the answer "forward it" or "these hosts have no validation slot to produce it from"?
• dependsOnLabels exists because only the FORM knows a sibling field's human label. Whether an inline host can produce it at all is unresolved.
• dataSource is currently unforwarded by design at one host: InlineFieldInput says so out loud ("No dataSource is needed — every record-querying type is routed above"), while ObjectGrid's inline editor relies on the widgets reading it from SchemaRendererContext instead.
• onSelectRecord / onCreateNew are also declarable on the field metadata, so "not forwarded as a prop" may be the intended single carrier.

So the honest triage question is whether each key should be DELIVERED or REMOVED from what this factory's props declare — the same enforce-or-remove fork the repo applies elsewhere. Guessing either way inside a repair PR would have been the consumer-side tolerance AGENTS.md #0.1 forbids.

Note on the second direction

Narrowing FieldEditWidget's declared prop type is a published contract change (it would break callers currently passing the keys, even though the keys are dropped today), which is why objectui#6909's dispatch reserved it for the maintainer. Same reservation applies here.

Unassigned and ungraded on purpose.

Generated by Claude Code

[os-sam]

Re-verified against merged main (b458300ca, i.e. after #7009 landed) — premise holds, and the card is stronger than I graded it. Re-grading p3 → p2.

I filed this from pre-merge state, so I re-measured it once #7009 was in main. All figures below are read from origin/main at b458300ca.

⚠️ Instrument note, recorded because it nearly cost me this measurement. My first census ran against the shared working checkout, whose HEAD is 26896c689 — not origin/main. It reported NumberField as not reading error, which is false on main (#7002 landed aria-invalid={!!error || !!refusal} at NumberField.tsx:86). Every count below is re-run with git grep <rev> against origin/main. Do not census this repo through the shared checkout.

What #7009 changed, and what it did not

#7009 made the body forward {...toDomProps(props)} plus the four semantic keys and compact. toDomProps' DOM_PASS_THROUGH_KEYS is id, name, autoFocus, tabIndex, onBlur, onFocus, onClick, className, disabled + the aria-* / data-* open families.

FieldWidgetComponentProps also declares a "Host plumbing: what a rendering host actually forwards" block. toDomProps correctly excludes all of it — those keys are not DOM-legal and forwarding them there would be the leak that helper exists to stop. But nothing else carries them either, so after #7009 these declared keys still never reach the widget:

error · dataSource · dependentValues · dependsOn · dependsOnLabels · emptyHint · onUploadingChange

(compact is the one member of that block #7009 does deliver, and only because the component sets it itself.)

Latent for most of the block — measured

Three in-repo non-test hosts call this component: RequiredFieldsDialog (plugin-kanban:125), InlineFieldInput (plugin-detail:434), ObjectGrid (plugin-grid:3571). None passes any host-plumbing key today, so for dataSource / dependentValues / dependsOn / dependsOnLabels / emptyHint / onUploadingChange this is a declared-but-undeliverable gap with no live in-repo victim. Consistent with the note on FieldEditWidget that the relational widgets read their dataSource from SchemaRendererContext, which the grid already provides.

⚠️ Worth stating precisely, because dataSource's own doc comment says it is "passed directly by inline-edit hosts" — this component is the inline-edit host, so the contract describes a wiring that does not exist on this path.

⭐ But error is LIVE, with a named host and a named consequence

RequiredFieldsDialog (packages/plugin-kanban/src/RequiredFieldsDialog.tsx:112-140) computes a real validation state and renders it visibly:

<FieldEditWidget field={f.def as never} value={values[f.name]}
 onChange={…} readonly={submitting} />
{showErrors && isMissing && (
 <span className="text-xs text-destructive">{tt('common.required', 'Required')}</span>
)}

The dialog has the error, shows it in red text, and cannot hand it to the widget — so the control's aria-invalid is never set. A sighted user sees the failure; a screen-reader user is not told. That is precisely the class #3222 and #3290 exist to close, and the one #7002 just closed for NumberField one layer down.

The consumer side is ready and it is not a corner: 34 of 56 non-test widget files under packages/fields/src/widgets/ carry aria-invalid, and the error readers include nearly all of EDIT_WIDGETS — SelectField, RadioField, CheckboxesField, MultiSelectField, TagsField, TextAreaField, NumberField, CurrencyField, PercentField, RatingField, EmailField, PhoneField, UrlField, ColorField, AddressField, LocationField, GeolocationField, CodeField, QRCodeField, LookupField. So the widgets would honour error the moment the factory delivers it. ⇒ The gap is entirely in this one destructure.

⭐ Bonus: #7009 falsified a comment in plugin-kanban

RequiredFieldsDialog.tsx:114-118 justifies its wrapping-label workaround like this:

FieldEditWidget renders the widget itself and takes no id to associate with, and widening its contract belongs to @object-ui/fields, not to a caller.

id is in DOM_PASS_THROUGH_KEYS, so as of b458300ca it does take an id. The workaround may still be the right rendering choice, but its stated reason is now stale, and a stale reason is how the next reader concludes the constraint still binds. Folding this into this card rather than filing a sixth one — it is one comment, in a file this card already has to touch to verify the fix.

Grading

p3 → p2. Not because the declaration gap grew, but because re-measurement turned "declared but undeliverable" into a named live a11y defect in a named host, with the whole consumer side already built.

Scope for whoever takes it (not yet dispatched)

• Forwarding these is not a widening: the keys are already declared on FieldWidgetComponentProps. That is the same argument fix(fields): FieldEditWidget forwards the DOM pass-through block it declares #7009 made and landed on, so the precedent is set in this exact file.
• ⛔ But do not route them through toDomProps — they are not DOM-legal and that helper's whitelist is deliberately closed. They need forwarding as component props, separately from the DOM block.
• ⚠️ Delivering dataSource to widgets that currently fall back to SchemaRendererContext can change behaviour if a host ever passes both. No host does today, but the fix should say which wins rather than leave a second authority — the repo has closed that shape repeatedly (field 与 schema 是同一个意思的两个载体,~25 个 widget 读 field || schema #3233's field || schema).
• Verification must include the kanban dialog case end-to-end: an inline-edit control that has failed required-validation reports aria-invalid.

---

Generated by Claude Code