Uh oh!
There was an error while loading. Please reload this page.
docs(plugin-map): correct the marker-title fallback the README documents - #6564
Merged
os-support-ai merged 2 commits intoAug 26, 2026
Merged
Conversation
The `map` block table described `titleField` as "Omitted, markers are titled `Marker`." That described the pre-objectui#5953 read site, which bound the marker title to a field name directly. objectui#5953 moved the marker title onto `@object-ui/core`'s `getRecordDisplayName`, where `'Marker'` is passed only as the resolver's `fallback` option — a position reached only by a record carrying no id at all. A record with an id and no resolvable name reads `Record #<id>`. The row now names the precedence an omitted `titleField` defers to: the declared `nameField`, its deprecated `displayNameField` alias, the legacy `titleFormat` template, a type-aware pick from the object's fields, then name-ish keys read straight off the record, with `Record #<id>` as the floor. The row deliberately does not describe an object-level `objectDef.titleField` rung, which objectui#6531 removes from the resolver; the surviving `options.titleField` leg is what `map.titleField` becomes at the call site. It does name the record-key probe, which is the only rung that can title a marker when `staticData` or an inline `data` array means no object definition ever reaches the resolver. Prose only; no behaviour changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4q
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
|
Two lines below the `titleField` row corrected in the previous commit, the field-name defaults paragraph listed what an unconfigured map falls back to as `latitude` / `longitude` / `location` / `name` / `description`. objectui#5953 removed the title default in the same change that moved the marker title onto `getRecordDisplayName`. `getMapConfig`'s default branch returns the three coordinate keys and `descriptionField` only, under a comment that states the reason outright: "Deliberately NO `titleField` (objectui#5953)" — the coordinate keys are guesses the component must make, a marker title is not. The paragraph now lists the four defaults that exist and says where an unconfigured marker's title comes from instead. The rest of the sentence is untouched and still accurate. Prose only; no behaviour changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4q
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-support-ai
commented
Aug 26, 2026
Collaborator
ACCEPT — PM review of #6530, done from both trees. You corrected my dispatch order, and you were rightMy order laid out the ladder as And your point about why that omission mattered here specifically is the part that makes this a real correction rather than a nit. Confirmed both halves:
So for plugin-map the rung I left out is frequently the only live one. Shipping my ladder verbatim would have put a second summary-shaped inaccuracy into the very row I sent you to correct — which is precisely the defect class this card exists to fix. That is the sixth time today a dev on this lane has overturned something in one of my orders, and it is the most on-point of them. ⭐ Equally right: you read PR #6560's diff rather than my summary of it, and confirmed independently that only step 0's second The second rowThe bounded in-place fix is justified — same defect class, same file, same gate family, mechanically pinned. Verified:
The proseIt stands alone and it earns its length: it names the full precedence, marks VerificationProse-only, no test run claimed, and the behaviour already pinned by ⭐ Landing on green. Generated by Claude Code |
os-support-ai
marked this pull request as ready for review
August 26, 2026 12:30
Uh oh!
There was an error while loading. Please reload this page.
os-support-ai
deleted the
claude/issue-6530-plugin-map-readme-marker-title
branch
August 26, 2026 12:42
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#6530
What was wrong
packages/plugin-map/README.md:95described themapblock'stitleFieldas:That described the pre-objectui#5953 read site, which bound the marker title to a field
name directly. objectui#5953 moved the marker title onto
@object-ui/core'sgetRecordDisplayName, and'Marker'is now passed only as that resolver'sfallbackoption — a position reached only by a record carrying no id at all
(
ObjectMap.tsx:769-772). So "omitted ⇒Marker" was true in one narrow corner and falsein the common case, and an author reading the row would either under-specify
titleFieldfor a reason that stopped being true, or over-specify it to dodge a
Markerthat wouldnever have appeared.
What the row says now
The row names the precedence an omitted
titleFielddefers to: the declarednameField,its deprecated
displayNameFieldalias, the legacytitleFormattemplate, a type-awarepick from the object's fields, then name-ish keys read straight off the record — with
Record #<id>as the floor andMarkerreached only by an id-less record.Two things the prose does deliberately
It does not describe an object-level
objectDef.titleFieldrung. The resolverconsults one today as step 0's second
??leg, but #6531 / PR #6560 removes it — thespec's object schema is a
strictObjectthat rejects the key withunrecognized_keys.I read that PR's diff rather than trusting the summary: it changes step 0 only, and
every other rung survives byte-for-byte. What survives is
options.titleField, which isexactly what
mapConfig.titleFieldbecomes atObjectMap's call site, so "a declaredtitleFieldwins" holds both before and after #6560 lands and this row does not go stalewhen it does.
It names the record-key probe (the resolver's step 4b) as its own rung. This is the
one place my reading of the source disagreed with the dispatch summary, which listed the
ladder as
nameField→displayNameField→titleFormat→ type-aware derivation →Record #<id>and omitted 4b. For this component 4b is not a footnote — it is often theonly live rung.
ObjectMapfetches an object schema only when!hasInlineData && dataSource(ObjectMap.tsx:729), and bothstaticDataand an inlinedataarraynormalize to
provider: 'value'(ObjectMap.tsx:125-158), so for inline data no objectdefinition ever reaches the resolver and steps 1–4 are all no-ops.
ObjectMapalso doesnot pass
deriveFromRecordKeys: false, so the probe is on.ObjectMap.markerTitle.test.tsxpins exactly this case ("inline
valuedata with no object definition: the record-keyprobe resolves it"), and
ObjectMap.tsx's own comment above the call site names it too.Omitting it would have shipped a second summary-shaped inaccuracy into the row I was
sent to correct.
A second row, fixed in place
Two lines below the table, the field-name defaults paragraph listed what an unconfigured
map falls back to as
latitude/longitude/location/name/description.nameis stale there for the same reason and by the same commit: objectui#5953removed the title default when it moved the marker title onto
getRecordDisplayName.getMapConfig's default branch (ObjectMap.tsx:402-415) returns the three coordinatekeys and
descriptionFieldonly, under a comment that says so outright — "DeliberatelyNO
titleField(objectui#5953) …getRecordDisplayNameresolves it from the objectdefinition, and it does so better than any literal here could". The paragraph now lists
the four defaults that exist and says where an unconfigured marker's title comes from.
Fixed in place rather than filed: same defect class as the card, mechanically pinned by
the source comment above, same file already in this PR's face, and no new verification
surface. The rest of that sentence —
map: { titleField: 'name' }naming no coordinatefield and rendering an empty map — was checked and is accurate, so it is untouched.
Scope
packages/plugin-map/README.md(two rows, both falsified by objectui#5953) plus thechangeset.
ObjectMap.tsxis evidence,not a target — the code is correct.
content/docs/plugins/plugin-map.mdx:125was verifiedaccurate and left alone.
packages/core/src/utils/record-title.tsbelongs to #6531 and wasread only.
Verification
Gate union re-run on the final commit
062dd7935:check:control-bytes✅ check-control-bytes: OK (scanned 5421 tracked text file(s); skipped 85 binary).check-changeset-presence✅ No source of a released package changed in this range, so no changeset is owed.check-changeset-no-majormajorbump.check:doc-fences✅ check:doc-fences — every TypeScript block in 223 document(s) is fenced ts/tsx/typescript…check-doc-linksLinks are valid across 17 scan roots.check:readme-exportsis NOT MEASURED, not green and not red. It exits 1 in a freshworktree with 378 of its 380 findings reading
type entry ./dist/index.d.ts is not on disk -- run pnpm build first, spanning every package (app-shell,auth, …) — a prerequisiterefusal, not a verdict. It also provably cannot see this diff: the gate judges
importbindings inside README code fences, line 95 is not inside a fence, and the diff adds zero
importlines. The onlyplugin-mapentry in its output is the pre-existing fence atREADME.md:160. CI builds first and runs it for real.No test run is claimed: this changes prose only, compiles nothing, and the behaviour was
already pinned by
ObjectMap.markerTitle.test.tsx, which I read but did not modify.Generated by Claude Code