You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Retires titleFormat from ObjectGrid's RELATIONAL_META_KEYS, in the same shape objectui#6711 used for reference_to_field on this same list: remove the key, record the measurement in the docblock beside the list, pin the absence at all three call sites, add a changeset.
What was measured
applyRelationalMeta copied eight keys off the object-schema field def onto every relational column's fieldMeta, at all three of generateColumns's column-building call sites. titleFormat was one of them and has zero readers on a FIELD meta.
This is a different kind of zero from objectui#6711's, and a stronger one. titleFormat is a real, live key with many readers — it simply has none on a field meta. The sweep did not fail to find readers; it found every member read of the identifier across packages/ and apps/ (tests included) and classified each one by its receiver:
OBJECT schema (the referenced object's, via getSchema(referenceTo))
param.titleFormat
app-shell/utils/paramToField.ts:181
resolved ActionParamDef
Zero field metas. RecordPickerDialog and lookupColumnDisplay take it as a prop, and the repo's single titleFormat= pass is titleFormat={refTitleFormat} in LookupField — object-schema sourced. So copying reference_to is what makes titleFormat work on this path, and copying titleFormat onto the meta reached nothing.
Note app-shell/utils/resolveActionParams.ts:536 reads field.title_format — snake_case, a different spelling on a different surface — and its line 249 titleFormat is a key in the RESOLVED_ONLY_PARAM_KEYS diagnostic-message table, not a read.
plugin-dashboard/src/recordFields.tsx had already recorded this exact measurement as its reason for not copying the key into that seam, so the key was a measured no-op in two seams and had been retired from only one.
Must-answer: is there a THIRD reader-less key? Enumeration, not examples
No. All seven surviving keys have a measured FIELD-meta reader. For each key, the reader and the surface it reads from:
Key
FIELD-meta readers
Reads from
Reader-less?
reference_to
fields/src/index.tsx:1941 (LookupCellRenderer, off the cell's field prop); LookupField.tsx:256 (fieldMeta?.reference_to); UserField.tsx:48 (meta?.reference_to)
LookupField.tsx:270; UserField.tsx:53 (second arm of the same ??)
FIELD meta
No
The first three are read on the cell path (getCellRenderer to LookupCellRenderer); the last four on the inline editor path, which is what makes them earn their place on this grid but not on the read-only dashboard seam.
The same sweep is the control against a blind instrument: it found a real reader for every surviving key, so its zero for titleFormat is a reading, not an artefact.
Reported, not acted on
lookup_filtersandlookupFilters are both on the list — one concept, two spellings, read at the same two sites as the two arms of a single ??. That is this repo's field || schema shape (objectui#3233). Left alone here per dispatch; flagging for triage.
The converse of this finding — keys the grid's own cell and picker read but never receive (displayField, reference_field, descriptionField, lookup_columns) — is already tracked as objectui#6875. Not duplicated.
Behaviour is provably unchanged
Not merely believed — three independent legs:
Static: every member read of the identifier is enumerated above; none is on a field meta.
Dynamic: the only computed access to the meta bag anywhere in @object-ui/fields or plugin-grid is applyRelationalMeta's own write (fieldMeta[key] = fieldDef[key]). No consumer bracket-reads or enumerates the bag (Object.keys/entries/values over it: zero hits), so there is no dynamic path by which the key's presence could reach a renderer.
Falsifiability: because a reader-less key changes no rendering, a green suite proves nothing — so the pin was reverse-verified. Re-adding titleFormat to the array turned the new pin red in exactly the predicted way: 3 failed / 3 passed, one failure per call site, with the survivor-presence controls staying green. Mutation confirmed on disk before the run (injected-text count 1, original 0, blob hash moved off the HEAD blob); restore confirmed after (git diff HEAD empty and hash back to the HEAD blob).
Second item: two stale descriptions re-synced
objectui#6711 falsified these when it landed; both are comments only.
plugin-dashboard/src/recordFields.tsx — the docblock enumerating RELATIONAL_META_KEYS as nine keys including reference_to_field, and "the grid's nine".
plugin-dashboard/src/__tests__/lookupRelationalMeta-6694.test.tsx — "copies NINE keys" and the fixture comment "The six the grid also copies".
⛔ The assertions in that test are untouched and still pin the dashboard's own three-key boundary — the diff on that file is comment lines only. All six keys stay on its fixture on purpose: that seam's boundary does not move when the grid's list does.
plugin-grid's own relationalMetaCopySet-6711.test.tsx needed its survivor control narrowed from eight keys to seven — that is the control set legitimately shrinking with the list it controls, the same edit objectui#6711 would have made to a predecessor.
Verification
Run from the repo root (canonical invocation; no -- before paths), heavy runs serialized through the shared verify lock.
Check
Command
Result
New pin + updated pin
pnpm exec vitest run packages/plugin-grid/src/__tests__/relationalMetaCopySet-6874.test.tsx packages/plugin-grid/src/__tests__/relationalMetaCopySet-6711.test.tsx
2 files, 12 passed
Reverse verification
key re-added, same pin re-run
3 failed / 3 passed — one failure per call site, as predicted; restored and confirmed
plugin-grid (full)
pnpm exec vitest run packages/plugin-grid/
100 files, 920 passed
plugin-dashboard (full) + every titleFormat reader test
All results above are from the final commit aa20ab010.
The type-check genuinely covers the new test file.packages/plugin-grid/tsconfig.json excludes **/__tests__/**, so a green tsc --noEmit alone would say nothing about it; the type-check script chains tsc -p tsconfig.test.json, and --listFiles on that project reports the new file as a program input (1 hit, out of 1757 program files). Confirmed rather than assumed.
Lint narrowing, declared. The repo-wide pnpm lint was not run; the two packages holding every changed file were linted in full instead. The narrowing is measured, not assumed: (1) the population comes from the repo's own wiring — git diff --name-only puts all changed files in exactly these two packages, and each package's lint script is eslint ., the same command CI's turbo run lint runs for them; (2) the counts are from full-package runs (419 and 706 problems), not a file subset; (3) eslint.config.js configures no type-aware linting (no project / projectService / parserOptions.project), so no rule reads cross-file type information and this diff cannot move the verdict on any file outside these two packages. CI runs the full farm regardless.
… key
`ObjectGrid`'s `RELATIONAL_META_KEYS` copied eight keys off the object-schema
field def onto every relational column's `fieldMeta`, at all three of
`generateColumns`'s column-building call sites. `titleFormat` was one of them
and has ZERO readers on a field meta.
This is a different zero from the one objectui#6711 acted on, and a stronger
one: `titleFormat` is a real, live key with many readers — it just has none on
a field meta. The sweep did not fail to find readers; it found every member
read of the identifier across `packages/` and `apps/` and classified each by
receiver. All of them are OBJECT schemas (`objectDef` / `objectSchema` /
`objSchema`, and `refObjectSchema?.titleFormat` in `LookupField` — the
referenced object's schema, which is what this grid's own inline picker reads).
The one remaining receiver is `param.titleFormat` on a resolved
`ActionParamDef`. So copying `reference_to` is what makes `titleFormat` work on
this path; copying `titleFormat` reached nothing.
Nothing renders differently, and that does not rest on the member sweep alone:
the only computed access to the meta bag in `@object-ui/fields` or
`plugin-grid` is `applyRelationalMeta`'s own write, so no consumer can pick the
key up dynamically.
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 seven survivors as the control against vacuity.
Also re-syncs the two `plugin-dashboard` descriptions of the grid's copy set
that objectui#6711 had already falsified — comments only; that seam's
assertions still pin its own three-key boundary and are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013hfmP9hoMd3dJwTh85J4yB
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.
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
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#6874
Retires
titleFormatfromObjectGrid'sRELATIONAL_META_KEYS, in the same shape objectui#6711 used forreference_to_fieldon this same list: remove the key, record the measurement in the docblock beside the list, pin the absence at all three call sites, add a changeset.What was measured
applyRelationalMetacopied eight keys off the object-schema field def onto every relational column'sfieldMeta, at all three ofgenerateColumns's column-building call sites.titleFormatwas one of them and has zero readers on a FIELD meta.This is a different kind of zero from objectui#6711's, and a stronger one.
titleFormatis a real, live key with many readers — it simply has none on a field meta. The sweep did not fail to find readers; it found every member read of the identifier acrosspackages/andapps/(tests included) and classified each one by its receiver:objectDef/objectSchema/objSchemacore/utils/record-title.ts,components/renderers/layout/containers.tsx,plugin-detail/DetailView.tsx,plugin-kanban/ObjectKanban.tsx,plugin-calendar/ObjectCalendar.tsx,react/hooks/useRecordSearch.tsrefObjectSchema?.titleFormatfields/widgets/LookupField.tsx:377getSchema(referenceTo))param.titleFormatapp-shell/utils/paramToField.ts:181ActionParamDefZero field metas.
RecordPickerDialogandlookupColumnDisplaytake it as a prop, and the repo's singletitleFormat=pass istitleFormat={refTitleFormat}inLookupField— object-schema sourced. So copyingreference_tois what makestitleFormatwork on this path, and copyingtitleFormatonto the meta reached nothing.Note
app-shell/utils/resolveActionParams.ts:536readsfield.title_format— snake_case, a different spelling on a different surface — and its line 249titleFormatis a key in theRESOLVED_ONLY_PARAM_KEYSdiagnostic-message table, not a read.plugin-dashboard/src/recordFields.tsxhad already recorded this exact measurement as its reason for not copying the key into that seam, so the key was a measured no-op in two seams and had been retired from only one.Must-answer: is there a THIRD reader-less key? Enumeration, not examples
No. All seven surviving keys have a measured FIELD-meta reader. For each key, the reader and the surface it reads from:
reference_tofields/src/index.tsx:1941(LookupCellRenderer, off the cell'sfieldprop);LookupField.tsx:256(fieldMeta?.reference_to);UserField.tsx:48(meta?.reference_to)referencefields/src/index.tsx:1942;LookupField.tsx:256;UserField.tsx:48display_fieldfields/src/index.tsx:1948;LookupField.tsx:252;UserField.tsx:49id_fieldLookupField.tsx:254(fieldMeta?.id_field || 'id')description_fieldLookupField.tsx:253(fieldMeta?.description_field ?? fieldMeta?.descriptionField)lookup_filtersLookupField.tsx:270;UserField.tsx:53lookupFiltersLookupField.tsx:270;UserField.tsx:53(second arm of the same??)The first three are read on the cell path (
getCellRenderertoLookupCellRenderer); the last four on the inline editor path, which is what makes them earn their place on this grid but not on the read-only dashboard seam.The same sweep is the control against a blind instrument: it found a real reader for every surviving key, so its zero for
titleFormatis a reading, not an artefact.Reported, not acted on
lookup_filtersandlookupFiltersare both on the list — one concept, two spellings, read at the same two sites as the two arms of a single??. That is this repo'sfield || schemashape (objectui#3233). Left alone here per dispatch; flagging for triage.displayField,reference_field,descriptionField,lookup_columns) — is already tracked as objectui#6875. Not duplicated.Behaviour is provably unchanged
Not merely believed — three independent legs:
@object-ui/fieldsorplugin-gridisapplyRelationalMeta's own write (fieldMeta[key] = fieldDef[key]). No consumer bracket-reads or enumerates the bag (Object.keys/entries/valuesover it: zero hits), so there is no dynamic path by which the key's presence could reach a renderer.titleFormatto the array turned the new pin red in exactly the predicted way: 3 failed / 3 passed, one failure per call site, with the survivor-presence controls staying green. Mutation confirmed on disk before the run (injected-text count 1, original 0, blob hash moved off the HEAD blob); restore confirmed after (git diff HEADempty and hash back to the HEAD blob).Second item: two stale descriptions re-synced
objectui#6711 falsified these when it landed; both are comments only.
plugin-dashboard/src/recordFields.tsx— the docblock enumeratingRELATIONAL_META_KEYSas nine keys includingreference_to_field, and "the grid's nine".plugin-dashboard/src/__tests__/lookupRelationalMeta-6694.test.tsx— "copies NINE keys" and the fixture comment "The six the grid also copies".⛔ The assertions in that test are untouched and still pin the dashboard's own three-key boundary — the diff on that file is comment lines only. All six keys stay on its fixture on purpose: that seam's boundary does not move when the grid's list does.
plugin-grid's ownrelationalMetaCopySet-6711.test.tsxneeded its survivor control narrowed from eight keys to seven — that is the control set legitimately shrinking with the list it controls, the same edit objectui#6711 would have made to a predecessor.Verification
Run from the repo root (canonical invocation; no
--before paths), heavy runs serialized through the shared verify lock.pnpm exec vitest run packages/plugin-grid/src/__tests__/relationalMetaCopySet-6874.test.tsx packages/plugin-grid/src/__tests__/relationalMetaCopySet-6711.test.tsxpnpm exec vitest run packages/plugin-grid/titleFormatreader testpnpm exec vitest run packages/plugin-dashboard/ core/record-title{,.stepNumbering} fields/lookupCellDisplay{Name,Field} components/page-header-title react/useRecordSearch plugin-map/ObjectMap.markerTitle app-shell/paramToField types/object-schema-metadata-spec-derivationpnpm --filter @object-ui/plugin-grid --filter @object-ui/plugin-dashboard type-checkDone, exit 0pnpm --filter @object-ui/plugin-grid --filter @object-ui/plugin-dashboard lintpnpm changeset:checkNo changeset declares a major bump, exit 0pnpm check:control-bytesOK (scanned 5822 tracked text files), exit 0All results above are from the final commit
aa20ab010.The type-check genuinely covers the new test file.
packages/plugin-grid/tsconfig.jsonexcludes**/__tests__/**, so a greentsc --noEmitalone would say nothing about it; thetype-checkscript chainstsc -p tsconfig.test.json, and--listFileson that project reports the new file as a program input (1 hit, out of 1757 program files). Confirmed rather than assumed.Lint narrowing, declared. The repo-wide
pnpm lintwas not run; the two packages holding every changed file were linted in full instead. The narrowing is measured, not assumed: (1) the population comes from the repo's own wiring —git diff --name-onlyputs all changed files in exactly these two packages, and each package'slintscript iseslint ., the same command CI'sturbo run lintruns for them; (2) the counts are from full-package runs (419 and 706 problems), not a file subset; (3)eslint.config.jsconfigures no type-aware linting (noproject/projectService/parserOptions.project), so no rule reads cross-file type information and this diff cannot move the verdict on any file outside these two packages. CI runs the full farm regardless.Generated by Claude Code