Repository navigation
fix(plugin-list): withhold the toolbar Search on tree and chart list views (objectui#10326) - #10510
Conversation
…views (objectui#10326) Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BP8CMtACxTdLjqR6rhd33C
…ctui#10250 sentence it falsifies Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BP8CMtACxTdLjqR6rhd33C
…objectui#10326) Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BP8CMtACxTdLjqR6rhd33C
|
changeset-claim-re-read
|
✅ 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
|
Contract reviewServed-tier: Rendered by an isolated review subagent spawned by the ① Derived judgments
② Semver level
③ Boundary flags
Implemented-by: VERDICT: PASS Generated by Claude Code |
Fixes #10326
Clause-②: no
Executes ruling 5825585515 (letter A): the toolbar Search is not offered on
treeorchartlist views, because a control that changes nothing is withheld. No newObjectTreeSchemakey and no search on aggregates (option B was not taken).What changed
packages/plugin-list/src/ListView.tsx, one decision and two readers of it:searchlessViewOnScreen = currentView === 'tree' || currentView === 'chart'is declared besidedatasetChartOnScreen, which PR objectui#10477 added for the Filter controls. It is spelled the same way.showSearch: ua?.search !== false && !searchlessViewOnScreen, and thetoolbarFlagsmemo lists the new primitive.searchInput/setSearchInput, andsearchTermis derived assearchlessViewOnScreen ? '' : searchInput. Every existing reader keeps readingsearchTerm: the fetch ($search, and the client-side filter for inline data), the export, the trigger andganttSearchTerm. So a term that is already set does not narrowListView's own fetch or export while a tree or chart is on screen. The typed term is kept, so switching back applies it again, andonSearchChangeis not called for the switch.Tests:
packages/plugin-list/src/__tests__/ListView.searchWithheldTreeChart-10326.test.tsx, 17 cases, with a stand-in registered for every view node type. Each case waits for its view's stand-in before it asserts anything.Mechanism assumptions, measured
toolbarFlags.showSearchis the only visibility decision. The withhold sits there, spelled the way the Filter withhold is. The applied-term gate reads the same const, so there is no second decision.showSearchwas stillua?.search !== falsethere. The new const keys oncurrentView === 'chart'whatever the binding, and the pins cover both the object-bound and the dataset-bound block.showSearchfolds intouserActions.searchinnormalizeListViewSchema, and the flag reads!== false, so an authoredtrueis the same as the default. On tree and chart, an authoreduserActions.search: trueis now accepted and not honoured. One case pins that. No refusal or warning exists for it, and none was added. This is left as an open question in the report, the same shape PR objectui#10477 left foruserActions.filter: trueon a dataset chart.initialSearchTerm: app-shell'sObjectViewrestores the per-view stored term throughreadListFilterState, and before this change a tree view could have stored one. The other is a switch inside one list. Both kept$searchonListView's fetch, which feeds the record count and the export. Both are gated now and pinned.Reverse proof (committed tree
a966cf01e, mutation viaablation-replace.mjs, each leg restored to the HEAD blob with an emptygit diff HEAD)userActions.search: truecases, the 3 restored-term cases, the switch caseshowSearchback toua?.search !== false)truecases, the switch casesearchTerm = searchInput)My first ablation attempt was a no-op: a shell-quoting error, exit 2, lock held 0s, nothing mutated. It was re-run through a script file, and the three rows above come from those runs.
Changesets
.changeset/10326-toolbar-search-withheld-tree-chart.md:@object-ui/plugin-listpatch..changeset/10250-self-querying-views-toolbar-state.md(pending): body only, frontmatter byte-identical. Its last sentence said "the toolbar Search box ontreeandchartviews" still does not reach those queries. That presupposes a box this change removes, so the sentence now says the box is not offered.check-changeset-overwritereports this edit as its case 2 (report-only).check-changeset-claimsflagged 7 pending changesets that nameListView.tsx(7070, 7499, 7773, 7780, 8990, list-user-actions-collision-5398, listview-comment-pair-4559). I read each paragraph: none says anything about the toolbar Search, and none is falsified. The objectui#10327 changeset is still pending and is about Filter only: still true. A wider grep of pending bodies for toolbar Search found 8317'suserActions.search !== falsefallback quote, which is still true as the default.Gates, all at
a966cf01eListView.tsxin app-shell, plugin-grid, types, core, react, plugin-calendar and scripts): 29 files, 875 tests passed.packages/plugin-list/: 92 files, 1094 tests passed.pnpm --filter @object-ui/plugin-list type-check(tsc --noEmit && tsc -p tsconfig.test.json) after the closure build (--filter '@object-ui/plugin-list^...' build, 12 packages): exit 0. The test project compiles the new file. An earlier run went red on a mistyped double in it, which is fixed ina966cf01e.check-changeset-presence,check-changeset-no-major,check-changeset-fixed,check-changeset-overwrite,check-changeset-claims,check-new-cross-file-line-citations(0 new),check-control-bytes,check-test-path-roots,check-pending-changeset-literals,check:unreferenced-sources: all exit 0.lintscript lints (eslint .under the rooteslint.config.js, with no package config). The eslint JSON output counts 2 files: 0 errors;ListView.tsxhas 183 warnings, the same per-rule counts as the base blob linted through stdin, and the test file has 0. Nothing about untouched files can change: the config has noparserOptions.projectorprojectService(no type-aware linting), and no local rule reads other files.--teston the 4 paths: NOT GOVERNED.check:sdui-registration-pinsexited 2 with its prerequisite unmet (it needs a console build). The diff adds no registration to shipped source; the stand-ins are registered only in test scope.Acceptance notes
ListViewthat has inlinedata, noobjectNameand no data source. ThereObjectTreehas no object provider and draws the hostdata, which the list's client-side search narrows. With the withhold removed, a restored term hid the non-matching row. With it, both rows are drawn and Search is absent. So on that configuration this removes a Search that did narrow the tree, though it cut the hierarchy (the triage comment names that cost). Nothing in examples, docs or apps authors a tree list view, and the console always bindsobjectNameand a data source. This is raised as an open question in the report and not acted on.searchableFieldson a view that is only a tree or only a chart is now read by nothing on that view. It still rides with the term once the list switches to a view that offers Search.Generated by Claude Code