Uh oh!
There was an error while loading. Please reload this page.
fix(plugin-map): resolve marker titles through getRecordDisplayName - #5975
Merged
Conversation
ObjectMap was the only view renderer outside ADR-0079's unified record display-name resolver. getMapConfig filled an absent title binding with the string literal 'name' and the marker transform did a bare record[titleField] read, so every object whose display field is not literally 'name' titled every marker popup undefined. Both literals are removed and the read site calls getRecordDisplayName, passing the declared binding as its explicit titleField option so an authored map.titleField still wins. objectSchema joins the marker memo's deps, since it arrives from an async fetch after first paint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CSoz9uGhaaSgiq3hshtN7L
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
|
This was referenced Aug 24, 2026
yinlianghui
marked this pull request as ready for review
August 24, 2026 10:31
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 24, 2026
This was referenced Aug 25, 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
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#5953
ObjectMapwas the only one of the four view renderers outside ADR-0079's unifiedrecord display-name resolver.
getMapConfigfilled an absent title binding with thestring literal
'name', and the marker transform then did a barerecord[titleField]read — so for every object whose display field is not literally
name, each markerpopup titled itself
undefined. This converges it onto@object-ui/core#getRecordDisplayName,the same call
ObjectKanban.tsx:301,ObjectCalendar.tsx:356andObjectGantt.tsx:600already make.
The change
At the marker read site:
The declared binding is passed through as the resolver's explicit
titleFieldoption rather than dropped, so an authored
map.titleFieldstill wins outright — theresolver checks that option first. No authoring surface changes and no new map config
keys: this is a bug fix, not a widening.
Three supporting edits:
getMapConfig, flat branch —titleField: schema.titleField || 'name'loses the|| 'name'. A forged binding is not merely useless, it is harmful: it outranks theobject's own declared
nameFieldat step 0 of the resolver.getMapConfig, default branch — the same literal,titleField: 'name', removed.Bounded in-place fix, declared: the issue names only the flat-branch literal, but
this is the same literal in the sibling branch of the same function, the same defect
class, and the correct shape is pinned by the same ADR-0079 evidence. Leaving it would
have kept the bug alive in a narrower form — a stray
namekey on a record beating adeclared
nameField. The surrounding coordinate guesses (latitude/longitude/location) stay: nothing but this component can read a location out of anunconfigured record, whereas a title is precisely what the resolver reads better.
objectSchemajoins the marker memo's dependency array. It lands from an asyncfetch after first paint, and the titles are now resolved from it; omitting it would
have left first-painted markers titled from a null object definition permanently.
The pinned test — what its subject actually is
The card flagged that
ObjectMap.listViewMapConfigReach.test.tsx"currently pins theundefined/placeholder behaviour". Measured, it does not. Every one of its six armsdeclares
titleField: 'title'and asserts a positive title ('Install rooftop unit','Bldg A'). Theundefined/'Marker'mention is prose in a comment at line 138,narrating history — there is no assertion on it anywhere in the file, and a repo-wide
grep for a
'Marker'string assertion returns only that comment and the source line.So the pin's subject is unambiguously reach — that a declared
mapblock arrives atgetMapConfigand drives the read — and it observes the bug not at all, incidentally orotherwise. It exercises the one path that was never broken: an authored binding. Nothing
in it is deleted, loosened or touched, and it stays green unchanged.
Placeholders: two competed, one line splits them
Once the resolver arrives it brings its own record-number floor —
Record #followed bythe record's id, e.g.
Record #77— alongside this component's'Marker'. They aresplit by whether the record has an id, because that is exactly the split in how much
either can say:
'Marker'was always weak here — everypin on a map is a marker, so the word separates none of them, while the id names
exactly one record.
'Marker'. Passed as the resolver's declaredfallbackoption, displacing its generic
'Untitled', which is the worse word for this surface.fallbackbeing a declared parameter ofgetRecordDisplayName, resolving this neededno change to
@object-ui/core— the shared surface the card fenced off.Tests
New:
packages/plugin-map/src/ObjectMap.markerTitle.test.tsx, 7 arms — the flat formwith no
titleField(the card's literal symptom), the declared block with notitleField, the authored-titleField-still-wins invariant, atitleFormattemplate,inline
valuedata where no object definition is ever fetched, and the two placeholderarms.
Reverse-verification. Reverting only
ObjectMap.tsxtoorigin/mainand re-runningthe file: 6 failed | 1 passed — the direction predicted before the run. The one
survivor is the authored-
titleFieldarm, which is correct: it pins an invariant thatwas never broken, not the defect. The mutation was confirmed on disk by anchored greps
in both directions before the run (deleted text restored: 1 hit; injected text gone: 0
hits; the
|| 'name'literal back: 1 hit), and the restore was trapped onEXIT INT TERM.No rebuild is involved on this leg: the root
vitest.config.mtsaliases every@object-ui/*specifier to that package'ssrc/, so the run resolves source directlyand no
dist/can go stale between legs.Gates below all ran on
9b93deawith a clean tree.vitest run packages/plugin-map/Test Files 14 passed (14)/Tests 83 passed (83)pnpm --filter @object-ui/plugin-map type-checktsc --noEmit && tsc -p tsconfig.test.json)pnpm --filter @object-ui/plugin-map lint✖ 110 problems (0 errors, 110 warnings)check-control-bytes✅ OK (scanned 4952 tracked text file(s); skipped 85 binary)check-changeset-presence✅ 2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)check-changeset-fixed/check-changeset-no-major✅ No changeset declares a major bumpplugin-view+plugin-list+app-shell)Test Files 4 passed (4)/Tests 39 passed (39)Lint was run over the whole
plugin-mappackage — the exact unit CI's lint jobcovers — not over my three files. The 110 warnings are all pre-existing
no-explicit-any/no-unused-varsacross the package's 21 files; the new test filecontributes 7 of them, in the same
vi.mockidiom every sibling file in the package uses(they run 5–12 each), and
.github/workflows/lint.ymlsets no--max-warnings.Other packages' lint jobs were left to CI, and that narrowing excludes nothing: the file
population came from eslint's own resolution rather than a hand-written list, the count
of 21 was read from
--format json, andeslint.config.jsenables no type-awarelinting (no
project/projectServiceinlanguageOptions), so no rule's verdict onan untouched file in another package can move as a result of this diff.
The repo-wide
pnpm checkfarm is CI's run, not re-derived here.Note: an earlier revision of this body spelled the record-number floor with an angle-bracket
placeholder; GitHub's body sanitizer ate the bracketed fragment on write. Respelled above.
Generated by Claude Code