Uh oh!
There was an error while loading. Please reload this page.
fix(core): $expand user/tree reference columns in list & grid views (not just lookup/master_detail) - #2032
Merged
Merged
Conversation
…st lookup/master_detail) List/grid views derive their `$expand` set from `buildExpandFields`, which only recognised `lookup` and `master_detail` field types. Reference columns of type `user` (and `tree`) were therefore never requested for expansion, so the cell received a bare foreign-key id and rendered a raw id / "—" placeholder instead of the related record's display name — even though the objectql backend resolves `user` through the same expand path as `lookup`/`master_detail`. Extend the expandable-type set to the full reference-bearing set (lookup / master_detail / tree / user) behind a single exported constant `EXPANDABLE_FIELD_TYPES` + an `isExpandableFieldType()` predicate. Visible- column scoping is unchanged: only the reference columns a view actually shows are expanded, so wide objects never pay to expand relations no cell will display, and an empty set still omits `$expand`. Every `$expand` caller (list, grid, kanban, calendar, gallery, timeline, gantt, tree, map, detail) routes through `buildExpandFields`, so this single change fixes them uniformly. Verified against framework examples/app-showcase: a grid showing `user`-type columns flips from a raw id to the related user's name. (`tree` display additionally needs objectql to materialise tree expansion — a backend follow-up.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
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.
The bug
In list / grid (and kanban / calendar / gallery / …) views, reference columns of type
userrender a bare id (or a "—" placeholder) instead of the related record's name. Record detail views render the same fields correctly.Example: a grid showing a
user-type "technician"/"owner" column showsVYVspo4Eb9vx9AwqV4ThlA4WNt8CeJ80instead ofDev Admin.Root cause
List/grid views derive their
$expandset frombuildExpandFields()in@object-ui/core(packages/core/src/utils/expand-fields.ts). It recognised onlylookupandmaster_detailfield types:So for a
user(ortree) reference column the view never requested$expand→ the API returned the raw foreign-key id → the cell had no related record to read a display name from → it rendered the raw id /—.The objectql backend already resolves
userthrough the same expand path aslookup/master_detail(it carries the samereference+ id storage). So the gap was purely on the request side, in objectui.lookup/master_detailcolumns were already fine (the previous fix added scoped$expandfor them) — which is why the bug looked type-specific.The fix
Extend the expandable-type set to the full reference-bearing set —
lookup/master_detail/tree/user— behind a single exported constant + predicate, and route the existing collection logic through it:useris the field type the backend can expand but the frontend wasn't requesting — this is the end-to-end fix.treematches the form layer'sDATA_SOURCE_FIELD_TYPES(lookup/master_detail/tree); it's a reference too, so it belongs in the set. Requesting it is harmless and forward-compatible (see follow-up below).Every
$expandcaller (list, grid, kanban, calendar, gallery, timeline, gantt, tree, map, detail) routes throughbuildExpandFields, so this one change fixes them uniformly.Why only the visible reference columns (unchanged, but the key design point)
buildExpandFields(fields, columns)already intersects with the view's columns, and that's preserved. A list is N rows; expanding a relation per row has a cost, and a list typically shows only 2–3 reference columns. So the default is:Wide objects never pay to expand relations no cell will show. Detail view keeps expanding all reference fields (no
columnsarg), as before.This is a pure-function change with the type set extracted as the single source of truth (
EXPANDABLE_FIELD_TYPES/isExpandableFieldType), unit-tested for: mixed columns pick out only reference types; non-reference columns never enter$expand; the visible-column intersection; and empty → no$expand.Verification (framework
examples/app-showcase)Stood up the app-showcase backend + the objectui console against it, on the
showcase_field_zooobject (which has one field of every type) via a small grid view exposing the relational columns. Seeded a record with a realuserreference.f_lookup(lookup)f_master_detail(master_detail)f_user(user)VYVspo4Eb9vx9…(raw id)f_owner(user)VYVspo4Eb9vx9…(raw id)f_tree(tree)——(see follow-up)Confirmed at the API layer too: with
$expand=f_userthe backend returnsf_user: { name: "Dev Admin", … }; without it (today's behavior) it stays a raw id.Tests / build
@object-ui/coreunit tests: 4683 passed (incl. the extendedexpand-fieldssuite — 23 cases).@object-ui/plugin-list: 131 passed;@object-ui/core&@object-ui/plugin-gridbuild clean.Follow-ups (intentionally NOT in this PR)
treedisplay: the frontend now requests$expandfortree, but objectql's expand resolver currently materialises onlylookup/master_detail/user, sotreecolumns still show—until the backend expandstreetoo. That's a framework change..objectui-sha/.framework-shabumped here. After this merges, it reaches the cloud runtime via a framework.objectui-shabump (then cloud's own pin) — left to a human to time.🤖 Generated with Claude Code