Uh oh!
There was an error while loading. Please reload this page.
fix(plugin-grid): retire the dead reference_to_field relational meta key - #6876
Merged
Merged
Conversation
…a key `ObjectGrid`'s `RELATIONAL_META_KEYS` copied nine keys off the object-schema field def onto every relational column's `fieldMeta`, at all three of `generateColumns`'s column-building call sites. `reference_to_field` had ZERO member reads anywhere in this repo or in the producer repo — no member access, no destructuring, no bracket read — and `@objectstack/spec`'s FieldSchema does not declare it, so nothing authorable emits it either. The control that makes that zero a reading: the same sweep over its list-mates finds real readers for each of them in `@object-ui/fields`. Removing a key nothing reads changes no rendering, so the suite proves nothing by staying green; the absence is pinned instead, at all three call sites, with a presence assertion on the eight survivors as the control against vacuity. Same defect class the sibling producer retired twice (objectui#6625 `decimals`, objectui#6597 `referenceTo`). Measured for objectui#6711.
Patch bump for `@object-ui/plugin-grid` — the copy set no longer writes `reference_to_field` onto a relational column's fieldMeta. Records what the sweep bounds: this repo and the producer repo, not host applications.
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-sam
marked this pull request as ready for review
August 30, 2026 09:03
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 30, 2026
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes#6711
ObjectGrid'sRELATIONAL_META_KEYSlisted nine keys thatapplyRelationalMetacopies offthe object-schema field def onto every relational column's
fieldMeta, at all three ofgenerateColumns's column-building call sites.reference_to_fieldis removed from thatlist. Nothing renders differently — the key had no readers — so the value of this PR is in
the measurement, and the pin that keeps the absence from being re-added silently.
The sweep, re-run on this branch's base (2c1c967)
Whole-repo, excluding
node_modules/dist/.git, the identifierreference_to_fieldoccurred in exactly five places, none of them a read:
No member access, no destructuring, no bracket read. The same sweep across the producer repo
(
objectstack,packages/+apps/) finds zero occurrences of the identifier at all, sonothing on either side of the seam writes or reads it.
The eight-mate control, re-measured, is what makes that zero a reading. Member-read
counts for the other eight entries, same instrument, same base:
.keymember readsreference_toLookupCellRenderer,FilterConditionField,UserFieldreferenceLookupCellRenderer,UserField,GridFielddisplay_fieldLookupCellRenderer,LookupField:252,UserField:49id_fieldLookupField:254description_fieldLookupField:253lookup_filtersLookupField:270,UserField:53lookupFiltersLookupField:270,UserField:53titleFormatreference_to_fieldtitleFormathas 15 member reads but not one of them is off a field meta — every readertakes it off an OBJECT schema (
refObjectSchema?.titleFormatinLookupField:377,objectDef?.titleFormatincore/utils/record-title.ts,objSchema?.titleFormatincontainers.tsx, the ADR-0079 chain in kanban / calendar / gantt / map / detail).plugin-dashboard/src/recordFields.tsxalready records that same measurement as its reasonfor excluding the key from its own copy set. So
titleFormatis a second dead entry in thislist of a slightly different kind. It is deliberately NOT removed here — that is a second
adjudication, filed as #6874 — but the measurement is written into the docblock beside the
list so the next reader is not misled by this PR's own control table.
The stop condition was checked before deleting
reference_to_fieldis an ad-hoc key on an untyped bag, not a member of a declared,published type:
applyRelationalMeta(fieldMeta: Record, fieldDef: Record)writes intoRecord<string, any>(the three call sites each build
const fieldMeta: Record<string, any> = ...; none of themspreads the field def wholesale, so this list is the only road onto the bag).
field={fieldMeta as any}, and the declared prop type isCellRendererProps.field: FieldMetadata(packages/fields/src/index.tsx:315).FieldMetadatadoes not declarereference_to_field—LookupFieldMetadatadeclaresreference_field, a different key — andBaseFieldMetadatacarries no index signature.@objectstack/spec@17.2.0'sFieldSchemadoes not declare it either: it is in none of thatschema's 64 props, and the string does not occur anywhere in the installed package.
carry it, so the copy is unreachable" — does NOT hold as stated, and this PR does not rely on
it. Six of the eight surviving mates (
reference_to,display_field,id_field,description_field,lookup_filters,titleFormat) are equally absent from the spec's 64props and are demonstrably live at runtime, because the object schema the grid reads is the
objectql runtime shape rather than the spec's authorable one. Spec absence is corroboration
here, not the discriminator. The discriminator is the zero-reader sweep.
Verification (all at 099ff6a unless noted)
pnpm exec vitest run packages/plugin-grid/— 98 files, 901 tests, all passed(VERDICT
command-exit 0). Run at 9be75d3, whosepackages/**tree is byte-identical to099ff6a; the only later commit adds
.changeset/6711-retire-reference-to-field.md.pnpm exec vitest run packages/plugin-grid/src/__tests__/relationalMetaCopySet-6711.test.tsx— 6 passed, re-run at 099ff6a (VERDICT
command-exit 0).pnpm --filter @object-ui/plugin-grid run type-check— green (VERDICTcommand-exit 0).Both projects run:
tsc --noEmitfor src andtsc -p tsconfig.test.json, which is the onethat compiles the new test file (
includenamessrc/**/*.test.tsx).pnpm check:control-bytes— OK, 5728 tracked text files.pnpm changeset:checkplusnode scripts/check-changeset-presence.mjs— all green;2 source files of 1 released package changed, 1 changeset declared.
pnpm check:phantom-deps,check:vi-mock-specifiers,check:self-import— all green.--no-inline-config --format json:2 files linted, 0 errors (213 + 7 pre-existing-style
no-explicit-anywarnings; thelint workflow deliberately sets no
--max-warnings). The narrowing is sound becauseeslint.config.jsenables no type-aware program (noproject/projectService), so adiff confined to two files cannot move any untouched file's verdict.
turbo run build --concurrency=2 --filter=@object-ui/plugin-grid^..., 12 tasks), becausetsconfig.test.jsonsetspaths: {}and resolves@object-ui/*through built.d.ts.The ablation, in the useful direction
A green suite proves nothing here: with no readers, removing the key changes no behaviour, so
every test stays green whether or not the removal is right. What is load-bearing is that the
new pin FAILS when the key comes back.
Measured: the key was re-inserted into
RELATIONAL_META_KEYSon a committed tree, and themutation was confirmed on disk before the run — array-entry count 0 to 1, blob hash
012b1actob12b7f2— not by the editor's exit code. Result:All three absence assertions red, one per call site, while the three control assertions
stayed green — so the red is specific to the re-added key, not a broken fixture. Restore leg
proven the same way:
git checkout HEAD -- ...with an absolute path under a trap, thengit diff HEADempty and the restored blob hash equal to the HEAD blob (012b1ac).No rebuild step is involved on either leg, and that is a property of this repo rather than an
omission:
vitest.config.mtsaliases every@object-ui/*specifier topackages/*/src, andthe test imports
../ObjectGridrelatively, so both legs read source and neverdist.The pin, and why it is shaped this way
packages/plugin-grid/src/__tests__/relationalMetaCopySet-6711.test.tsxreplaces theregistered
lookupcell renderer with a probe (getCellRendererchecks the registry first,so the probe receives exactly the bag the shipped renderer would get) and drives all three
column-building shapes: ListColumn objects, a string array, and the inline-data path with an
authored
fieldsprojection.Each case asserts the absence AND that the eight surviving keys are present. The presence
half is not decoration — the first draft of this test passed vacuously, because the object
schema arrives from an async fetch and the first paint hands the renderer a bare
{ name, type }on which the absence assertion is trivially true. The fixture now waits forlabel(written from the sameobjectDefFieldblock immediately beforeapplyRelationalMeta, and not itself under test) before measuring.What this does not establish
The sweep bounds this repo and the producer repo. A host application outside them could be
reading
reference_to_fieldoff thefieldMetaits cells receive; that was never a promisethis renderer declared, but the world was not measured, and such a host gets
undefinedafter this change. The changeset says so in the same words.
Card relationships
reference_to_fieldonto every column's fieldMeta, and nothing in the repo reads it #6711.titleFormatin ObjectGrid's RELATIONAL_META_KEYS has zero FIELD-meta readers — every reader takes it off the OBJECT schema #6874 — filed from this work:titleFormatis a second dead entry in the same list (zeroFIELD-meta readers), plus the two
plugin-dashboardcomments that go stale once thislands. Deliberately out of scope here; not touched by this PR.
displayField,reference_field,descriptionField,lookup_columnsnever arrive) #6875 — filed from this work: the same list is a strict subset of what the grid's ownlookup cell and inline picker read (
displayField,reference_field,descriptionField,lookup_columnsnever arrive). The opposite direction from this card; out of scope here.decimals) and objectui#6597 (referenceTo), bothretired from the sibling producer.
Generated by Claude Code
Generated by Claude Code