refactor(views): ListView resolves density from the spec-canonical rowHeight (#2890) - #2933
Merged
Merged
Conversation
…owHeight` (#2890) Second rename in the ListView vocabulary migration: `densityMode` → `rowHeight`, folded in the same `normalizeListViewSchema` step 1 introduced. Not a pure alias — the vocabularies are different sizes. The spec has five row heights, ListView's toolbar offers three densities. Both directions now live in one place (`DENSITY_MODE_TO_ROW_HEIGHT` / `ROW_HEIGHT_TO_DENSITY_MODE`, plus the tolerant `rowHeightToDensityMode` reader), chosen so a fold followed by a read is a round trip and the lossy narrowing is stated once. Two behavior fixes fall out: - Precedence is no longer inverted. ListView read `densityMode` FIRST, so a view carrying both keys rendered the legacy value — backwards from every other legacy/canonical pair. The canonical key now wins. - The toolbar stops re-seeding the legacy key: ObjectView's `onDensityChange` persisted `densityMode` into stored view metadata on every toggle, so the legacy vocabulary kept regrowing underneath the migration. Co-Authored-By: Claude <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 free
to 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.
Second rename in #2890 scope A:
densityMode→rowHeight, folded in the samenormalizeListViewSchemathat #2932 introduced.Not a pure alias
Unlike
fields/columns, the two vocabularies are different sizes: the spec has five row heights (compact/short/medium/tall/extra_tall), ListView's toolbar offers three densities (compact/comfortable/spacious). Both directions now live in one place —DENSITY_MODE_TO_ROW_HEIGHT(widening, used by the fold and by persistence)ROW_HEIGHT_TO_DENSITY_MODE+ the tolerantrowHeightToDensityMode()reader (narrowing, used by the renderer)— chosen so a fold followed by a read is a round trip (
spacious→tall→spacious), with the lossy collapse (short→compact,extra_tall→spacious) stated once instead of re-derived per call site. Tests pin both properties.Two behavior fixes fall out of it
ListView'sresolvedDensityreaddensityModefirst, so a view carrying both keys rendered the legacy value — backwards from every other legacy/canonical pair in the schema (columnsbeatsfields,userActionsbeats theshow*flags). The canonical key wins now. The test that asserted the old order (should prefer densityMode over rowHeight) is inverted accordingly, and a companion test pins that a legacy-only view still resolves through the fold.ObjectView'sonDensityChangepersisteddensityModeinto stored view metadata on every density toggle — so the legacy vocabulary kept regrowing underneath the migration, and stored views drifted into carrying both. It persistsrowHeightnow.densityModestays declared onListViewSchemaand in the drift guard's sanctioned set — stored views carry it and it is still valid input — but it is input-only.Verification
normalize-list-view.test.ts+5 tests: fold, canonical-wins, unrecognized-value passthrough, and the two vocabulary-size properties (round trip in the widening direction, total coverage in the narrowing one).ListView.test.tsx: the precedence test inverted, plus a legacy-only fold test.core,types,plugin-list,plugin-view,app-shellpass;turbo run type-checkover the four touched packages (32 tasks) passes; ESLint 0 errors.Stacked on #2932 (merged); rebased onto
main.🤖 Generated with Claude Code