fix(plugin-grid): retire the FIELD-meta-dead titleFormat relational key - #7020
Merged
Merged
Conversation
… 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
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 31, 2026 13:10
os-sam
enabled auto-merge
August 31, 2026 13:10
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 free
to 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 #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