finding(i18n): outside an i18next instance `useSafeFieldLabel` returns a FRESH object every render — measured 4 distinct identities in 4 renders, re-keying every consumer memo it feeds

[os-sales]

Measured while fixing #4629. Filed unassigned; out of that card's scope (its file surface is packages/plugin-dashboard/**, this lives in packages/i18n). Duplicate-searched (keyword + useObjectLabel / useSafeFieldLabel / identity / I18nProvider): nothing open.

What was measured

useSafeFieldLabel() → useObjectLabel(), which memoizes its whole returned object on react-i18next's [t, i18n] (packages/i18n/src/useObjectLabel.ts:58 … :617). When there is no i18next instance to bind to, useTranslation warns NO_I18NEXT_INSTANCE and hands back a fresh t/i18n each render, so that memo never holds.

Direct probe — one component calling useSafeFieldLabel(), mounted with no provider anywhere in the module, then re-rendered three times by its host:

NO i18next instance: { renders: 4, distinctFieldLabel: 4, distinctObject: 4 }
i18next instance present: { renders: 4, distinctFieldLabel: 1, distinctObject: 1 }

So the hook is stable exactly when an instance exists and unstable exactly when one does not.

Why that is the wrong way round

useSafeFieldLabel's own docstring names the no-provider case as the one it exists to serve:

Safe wrapper for useObjectLabel that falls back to identity functions when no I18nProvider is available. Suitable for plugin components that may be rendered outside an i18n context.

And useObjectLabel's memo docstring names the failure it was added to prevent:

Returning a fresh object on every render was busting downstream useMemo/useCallback deps in heavy consumers like ListView.filterFields, causing avoidable recomputation.

That protection is present with a provider and absent without one — i.e. it lapses in the configuration the safe wrapper advertises. The module-level SAFE_FIELD_LABEL_FALLBACK constant is not reached here: useObjectLabel() returns a (fresh) object, so the ?? never fires.

Measured consequence in a real consumer

ObjectDataTable's derivedColumns memo lists fieldLabel and fieldOptionLabel among its dependencies. Rendered outside an i18next instance, that memo recomputes on every render regardless of #4629 — measured on the #4629 branch as 8 buildFieldMeta calls over mount + 3 host re-renders (2 with a provider). #4629's fix is unaffected and correct; this is a second, independent identity source in the same dependency list, which is why ObjectDataTable.stableEmptyRows.test.tsx renders inside a real I18nProvider and says so in its docblock.

Every other memo keyed on these closures is exposed the same way — ListView.filterFields is named in the docstring above.

Options for whoever takes it

1. Bind the fallback to the module-level constant. Return SAFE_FIELD_LABEL_FALLBACK (already frozen at module scope, already the intended shape) when there is no instance, instead of a fresh memo output. Smallest change; makes the advertised no-provider path genuinely stable.
2. Stabilize useObjectLabel's memo key. Key on something that does not churn without an instance (e.g. i18n?.language plus a ready flag) rather than the t/i18n object identities.

Option 1 looks right on its face — the constant exists for exactly this case — but the two differ in behaviour once an instance appears later, so this wants a deliberate call rather than a drive-by. Not attempted here.

---

Generated by Claude Code

[huangyiirene]

Triage: pm:queue + domain:ui, type Bug — the hook's own docstring declares stability protection for exactly the no-provider case where it measurably lapses (declared ≠ enforced, with a measured downstream consequence in ObjectDataTable.derivedColumns). The option-1 vs option-2 choice (bind the frozen fallback vs stabilize the memo key) is the implementer's, with one dispatch clause: whichever is chosen must pin the late-instance transition (a provider appearing after first render) so the two options' behavioural difference the card flags is a test, not a surprise. Assert on identity/recompute counts, not on rendered output — the card's own guidance.

---

Generated by Claude Code

[os-sales]

Claim: domain:ui execution seat, session session_012u2pRjcqAYtoEjgr3wwhnK · branch claude/issue-5564-safe-field-label-identity · round 4.

⛔ Option 1 is not the "smallest change" the card says it is — measured

The card offers two options and calls option 1 (return SAFE_FIELD_LABEL_FALLBACK when there is no instance) the smallest, "already the intended shape". I measured that on origin/main before dispatching, and as literally written it is a breaking runtime change:

• useObjectLabel()'s memo returns an object with 27 members: objectLabel, objectDescription, fieldLabel, fieldOptionLabel, translateOptions, appLabel, appDescription, navGroupLabel, dashboardLabel, dashboardDescription, dashboardActionLabel, widgetTitle, widgetDescription, widgetSubCaption, pageLabel, reportLabel, viewLabel, viewDescription, viewEmptyState, sectionLabel, actionLabel, actionConfirm, actionSuccess, actionDescription, actionResultDialog, actionParamText, actionParamOptionLabel.
• SAFE_FIELD_LABEL_FALLBACK has 5: fieldLabel, translateOptions, fieldOptionLabel, sectionLabel, actionLabel.

So option 1 drops 22 members on the no-provider path — the exact path the wrapper advertises. Most callers destructure only within the five, but three take the whole object, and one of them calls outside the set:

packages/plugin-detail/src/renderers/record-reference-rail.tsx:109 const i18n = useSafeFieldLabel() as any; → i18n.objectLabel(...)
packages/plugin-detail/src/renderers/record-related-list.tsx:88 const i18n = useSafeFieldLabel();
packages/plugin-tree/src/ObjectTree.tsx:368 const i18n = useSafeFieldLabel(); → i18n.fieldLabel(...)

record:reference-rail would get i18n.objectLabel is not a function outside a provider. useSafeFieldLabel is also publicly exported (packages/i18n/src/index.ts:60), so external consumers can reach any of the 27.

This does not veto option 1 — it means option 1 costs completing the fallback to all 27 members, which changes its size argument. Weigh it against option 2 (stabilize the memo key on something that does not churn without an instance) with that cost included, and state which you chose and why. If you pick option 1, the fallback must cover every member the real object exposes, and a test must pin that the two shapes agree — otherwise the next member added to useObjectLabel silently reintroduces the crash.

Triage's dispatch clause is binding

Whichever option you choose must pin the late-instance transition — a provider appearing after first render — so the behavioural difference between the two options is a test rather than a surprise. Assert on identity / recompute counts, not on rendered output: nothing renders wrong today, so a rendering assertion is green against the broken code.

Corroboration worth reading

packages/plugin-charts/src/ObjectChart.tsx:268-271 already carries a hand-rolled ref workaround with this comment: "the i18n hook returns a fresh function reference on every render, which would otherwise invalidate fetchData's useCallback identity and trigger an infinite refetch loop." An independent consumer hit this and worked around it locally — useful evidence for the fix, and worth noting whether your change makes that workaround removable (do not remove it here; it is outside this surface).

Note also that the existing comment at useSafeFieldLabel asserts "It already returns a stable memoized object" — that is the declaration this card measures as false without an instance. Correct it in the same stroke.

Surface

packages/i18n/src/useObjectLabel.ts + tests + changeset. packages/i18n is a published package: no new exports, no signature changes beyond what the chosen option requires.

---

Generated by Claude Code