Filed unassigned by the dev seat working objectui#6343 (session session_011SfZeFWrhGLHmfq61xbz4q), measured while weighing whether the derived marker-title binding removed there was covering anything other than precedence. Observation-class: no user report behind it, and the window is transient. ⛔ Out of that PR's file face. Duplicate scan: 247 open objectui issues enumerated via the REST list endpoint and grepped for getObjectSchema / ObjectMap / marker / record title; no hits on this subject.
The shape
ListView renders these plugins with objectName plus the already-fetched rows, and each plugin then fetches the object definition again for itself:
packages/plugin-map/src/ObjectMap.tsx:546 — const [objectSchema, setObjectSchema] = useState<any>(null), filled by a dataSource.getObjectSchema(objectName) effect (:711-732).packages/plugin-kanban/src/ObjectKanban.tsx:231-239 — the same pattern.
Marker / card titles are resolved from that definition (ObjectMap.tsx:769, ObjectKanban.tsx:364), and the file already records the consequence in a comment:
objectSchema is a dependency now, not incidentally: it lands from an async fetch AFTER the first paint, and the titles above are resolved from it.
So between first paint and schema arrival, getRecordDisplayName(null, record, …) runs with no object definition: steps 1-4 are all unavailable, and the title comes from the record-key probe (name/title/subject/…) or the Record #<id> floor. An object whose display field is name-ish is unaffected; one keyed by an affix-convention field (site_name) or by a titleFormat template paints Record #<id> first and flips to the real title a moment later.
Why it is only a finding
It is transient, it is identical across the map and the kanban (so nothing is inconsistent between visualizations), and it does not affect the settled state. It is recorded because it was the one substantive argument for keeping a statically-derived title binding at the interface-page seam (objectui#6343) — a static field name is available synchronously, a fetched definition is not. That argument was rejected there on the ground that ObjectKanban lives with the same window and carries no derived binding, and that papering over it per-seam is what produced the inverted precedence in the first place. The general fix, if it is worth one, is at the renderer: hand the definition down from ListView, which already has it, instead of refetching — that also covers the paths no upstream deriver reaches (hand-declared map blocks, non-interface-page maps).
Worth grading against the startup-scope bar: a one-render title flicker may simply not be worth a prop-plumbing change across two plugins.
Refs: objectui#6343 · objectui#5953 / PR #5975.
Filed unassigned by the dev seat working objectui#6343 (session
session_011SfZeFWrhGLHmfq61xbz4q), measured while weighing whether the derived marker-title binding removed there was covering anything other than precedence. Observation-class: no user report behind it, and the window is transient. ⛔ Out of that PR's file face. Duplicate scan: 247 open objectui issues enumerated via the REST list endpoint and grepped forgetObjectSchema/ObjectMap/marker/record title; no hits on this subject.The shape
ListViewrenders these plugins withobjectNameplus the already-fetched rows, and each plugin then fetches the object definition again for itself:packages/plugin-map/src/ObjectMap.tsx:546—const [objectSchema, setObjectSchema] = useState<any>(null), filled by adataSource.getObjectSchema(objectName)effect (:711-732).packages/plugin-kanban/src/ObjectKanban.tsx:231-239— the same pattern.Marker / card titles are resolved from that definition (
ObjectMap.tsx:769,ObjectKanban.tsx:364), and the file already records the consequence in a comment:So between first paint and schema arrival,
getRecordDisplayName(null, record, …)runs with no object definition: steps 1-4 are all unavailable, and the title comes from the record-key probe (name/title/subject/…) or theRecord #<id>floor. An object whose display field is name-ish is unaffected; one keyed by an affix-convention field (site_name) or by atitleFormattemplate paintsRecord #<id>first and flips to the real title a moment later.Why it is only a finding
It is transient, it is identical across the map and the kanban (so nothing is inconsistent between visualizations), and it does not affect the settled state. It is recorded because it was the one substantive argument for keeping a statically-derived title binding at the interface-page seam (objectui#6343) — a static field name is available synchronously, a fetched definition is not. That argument was rejected there on the ground that
ObjectKanbanlives with the same window and carries no derived binding, and that papering over it per-seam is what produced the inverted precedence in the first place. The general fix, if it is worth one, is at the renderer: hand the definition down fromListView, which already has it, instead of refetching — that also covers the paths no upstream deriver reaches (hand-declaredmapblocks, non-interface-page maps).Worth grading against the startup-scope bar: a one-render title flicker may simply not be worth a prop-plumbing change across two plugins.
Refs: objectui#6343 · objectui#5953 / PR #5975.