Uh oh!
There was an error while loading. Please reload this page.
docs(app-shell): grid-columns pin measures identity churn, not a column change - #6835
Merged
Conversation
…mn change `StudioDesignSurface.gridColumns.test.tsx`'s second case was documented as "a REAL column change still refetches — the dependency stays live". Since cloud#1652 added the `publishedFieldNames` filter to `gridColumns`, that is no longer what it drives: "+ Add field" appends an unpublished `field_N` to the draft, `publishedFieldNames` is read from the server baseline alone and so filters it back out, and what reaches the grid is an array of EQUAL CONTENT carrying a FRESH IDENTITY. The case pins identity-churn liveness, and its prose asserted the opposite. Measured on origin/main: across the click `find()` goes 1 -> 2 while `$select` stays `["id","name","status"]`, and no `field_` ever reaches the projection. Comment and test title only — the assertion, the path it drives and the coverage are untouched. The genuine content-change case is pinned in plugin-list's `ListView.discardedExpandFieldsMemo.test.tsx` (objectui#6697), which moves `$select` while holding `$expand` byte-identical. Refs objectui#6729. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CRJge11jso9TpXRWFt1Z49
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-sam
marked this pull request as ready for review
August 30, 2026 03:35
Uh oh!
There was an error while loading. Please reload this page.
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
3 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#6729
What moved
Comment and test title only, in
packages/app-shell/src/views/studio-design/StudioDesignSurface.gridColumns.test.tsx. The assertion, the button it clicks, the field it drives and the coverage are all untouched — visible in the diff as unchanged context lines.The second case was documented as "a REAL column change still refetches — the dependency stays live". Since cloud#1652 added the
publishedFieldNamesfilter togridColumns, that is no longer what it drives:addFieldappends an unpublishedfield_NtoobjDraft.fields(StudioDesignSurface.tsx:2455-2463) — a draft edit; nothing is published, andsetPublishedFieldNamesis not called.gridColumnsrecomputes (its dep isobjDraft.fields), then ends with.filter((n) => publishedFieldNames.has(n))(:2407), andpublishedFieldNamesis populated from the server baseline alone (:2349, thelayered()response) — never from the draft.field_Nis filtered back out, and what reaches the grid is an array of equal content carrying a fresh identity. There is no remount to explain the refetch either: the grid's key iscurrent.nameplusgridVer(:2900), andgridVerdoes not move.The case therefore pins identity-churn liveness, and its prose asserted the opposite. The new docstring states that, names cloud#1652 as the cause so the next reader does not re-derive it, and points at where the genuine content-change case actually lives.
Triage order — which branch this took
The card made dispatch conditional on two preconditions. Both verified against
origin/main, not a branch and not the card:git log origin/main --grep='#6725'gives06b8c42f6 fix(plugin-detail,components,plugin-list): re-key three fetch effects onto the primitives they read (#6697) (#6725).packages/plugin-list/src/__tests__/ListView.discardedExpandFieldsMemo.test.tsxis present onorigin/main— added by that same commit, a positive control that ties the two together — and carries the casestill DOES re-fetch when the columns change WITHOUT changing what must be expanded: the column content moves (['name','account']to['name','account','status']),$expandstays byte-identical at['account'], a refetch is asserted, and$selectis where the change is read. That is verbatim the case the card quoted as the one census(finding): three more renderer fetch effects key on a memoised object identity, outside objectui#6592's dataConfig family #6697's repair had to add.⇒ branch 2: correct the prose and change nothing else. Not branch 3, so nothing here needs a ruling, and option B is not opened.
Measurement behind the new docstring
Rather than deriving the drift from source alone, I drove the real pillar with a throwaway probe (an untracked copy of the suite, deleted before the commit — the tree is clean) and recorded what the grid actually asks for across the click:
with
expect(select_after).not.toContain('field_')green. So the click does refetch (1 to 2), the projection is unchanged, and the new field never reaches it. Identity churn is the entire trigger — which is what the docstring now says.Verification
All at
3e4dfa200.git diff HEADandgit status --shortare both empty, so the tree every gate below ran against is exactly this commit.Run from the repo root with repo-root-relative paths — never
pnpm --filter PKG exec vitest, which re-roots at the package and cheerfully reports another package's files as passing. The reporter confirms the root and the executed file names:turbo run lint --concurrency=2→Tasks: 47 successful, 47 total, every package reporting0 errors(the standing warnings are pre-existing and untouched). The edited file produces no output at all, not even a warning.turbo run type-check --filter @object-ui/app-shell→Tasks: 30 successful, 30 total, runningtsc --noEmit && tsc -p tsconfig.test.json. The second project is the one that matters here: itsincludeissrc/**/*.test.ts(x), so the edited file is genuinely in the program rather than excluded from it.grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]'on the edited file — no hits.Changeset
Owed, and declared as releasing nothing. The gate's own verdict decided it rather than my reading: with the edit alone it printed
because
check-changeset-presence.mjsdeliberately has no carve-out for test files undersrc/— its header says such a change "is answered by the empty-frontmatter exemption, in one line". Added.changeset/olive-donkeys-smoke.mdwith empty frontmatter; the gate now printscheck-changeset-no-major.mjsis green as well. No files undercontent/docs/releases/were touched.Out of fence
Nothing filed — no unrelated defect surfaced. The one non-green thing in this run was a second case in my own throwaway probe, which looked for the new field's machine name in the DOM; the inspector renders its label, not
field_N. That was a probe-authoring miss in a file that no longer exists, not a product finding.Generated by Claude Code