Skip to content

Both plugin-form catalog entries author form (a @object-ui/components type), never object-form — the third instance of #5113's class #6167

Description

@yinlianghui-tw

Filed unassigned while implementing #6024 (generalizing the catalog "entries use their own plugin" pin). Not claiming.

What was measured

#6024 replaced the pin's hand-enumerated category -> type table with a map DERIVED from the register() calls (deriveRegistryKeys in scripts/check-doc-component-types.mjs, joined on the packages/<dir>/... registration site). The first run of that derivation turned plugin-form red.

content/docs/plugins/plugin-form.mdx mounts both entries under ## Interactive Examples, inside <PluginLoader plugins={['form']}>:

<SchemaExample id="plugin-form/basic-form" />
<SchemaExample id="plugin-form/contact-form" />

Both author a root type: "form" with fields[] of input / select / checkbox / textarea. Measured against the register calls, none of those belong to @object-ui/plugin-form:

typeregistered by
formpackages/components/src/renderers/form/form.tsx:962
inputpackages/components/src/renderers/form/input.tsx:66
selectpackages/components/src/renderers/form/select.tsx:70
checkboxpackages/components/src/renderers/form/checkbox.tsx:56
textareapackages/components/src/renderers/form/textarea.tsx:58

packages/plugin-form registers exactly: object-form, embeddable-form, form-analytics, object-master-detail-form, record:line_items, view:form (plus the plugin-form:-namespaced spellings). Neither entry authors any of them.

This is the same defect #5113 (plugin-view) and #5856 (plugin-grid) were filed on: an example sitting on a plugin's docs page, inside that plugin's PluginLoader, that never exercises the plugin. Both tiles draw perfectly well — the @object-ui/components form renderer is real — so every existing check is green on them: check-doc-component-types asks only that a type is registered, and the objectui#4616 sweep asks only that the tile draws.

Why the card that found it did not fix it

#6024's own note is that the enumerated table it replaced was already wrong here — the filing table read plugin-form form, inheriting the assumption that form belongs to plugin-form. So the derivation earned its keep on its first run, but rewriting two catalog entries is entry-authoring work of the #5856 shape, not gate work.

Both entries are ledgered in OWN_PLUGIN_DEBT in examples/schema-catalog/test/catalog-gallery-render.test.tsx, keyed to this issue, with a case that asserts they STILL FAIL — an entry that starts conforming turns that file red until its ledger line is deleted, so the ledger cannot rot green.

What the fix has to cover — it is wider than the two JSON files

apps/site/app/components/registerCatalogBlocks.ts does not import @object-ui/plugin-form, so object-form is not in the gallery's registration set at all. An entry rewritten to author object-form would paint the OBJUI-001 "Unknown component type" panel in the docs gallery and turn the #4616 sweep red. So the change is at least:

  1. add @object-ui/plugin-form to registerCatalogBlocks.ts (and to HOST_PACKAGES in catalog-gallery-render.test.tsx, which mirrors it in order);
  2. rewrite the two entries as real object-form nodes bound to users, the object the gallery fixture serves — which would also earn them the DATA half of the Generalize the catalog "entries use their own plugin" pin to every plugin-* category — #5856 removed its last obstacle #6024 pin (a record that exists only in the fixture reaching the screen), the same way Both plugin-grid catalog entries are hand-built static card layouts that never author object-grid — the last instance of #5113's class #5856's rewrite did for plugin-grid;
  3. delete the two OWN_PLUGIN_DEBT lines.

Note also that adding a plugin package to the host list is not free: #4600's separation (the per-page demo hosts opt in through PluginLoader, so a docs page carrying a demo does not eagerly load every plugin graph) still applies, and check:eager-closure measures that budget.

Whether the two existing entries should be deleted or re-seated under components-form-* is a judgment call for whoever takes this: #5856 re-seated its two rather than deleting them, because deleting a catalog entry moves three corpus-wide counters (NODE_CENSUS in layout-dom-leak-5574.test.tsx, and two floors in layout-props-conversion.test.tsx), and a floor that moves because a fixture was deleted is indistinguishable later from one that moved because coverage regressed.

Severity

Left to triage. Read as a defect it is two entries teaching a reader that @object-ui/plugin-form's Interactive Examples are a plain form — the plugin's actual value (metadata-driven forms over one record) is undemonstrated on its own page. Read as debt it is the last known open instance of #5113's class.

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpm:dispatched

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions