fix(bases): keep Task List groups collapsed on first render

[renatomen]

Problem

A Task List base view configured with Default collapsed state: Collapsed renders every group collapsed, but the first chevron click does the opposite of what you ask: the clicked group stays collapsed and every other group expands.

Root cause

The collapse default is seeded during render, then overwritten by a state snapshot captured before that render.

1. The first render() returns early because Bases has not delivered data yet (the !this.data?.data guard in src/bases/TaskListView.ts). collapsedGroups is still empty.

2. Data arrives and onDataUpdated() runs the debounced render wrapper in src/bases/BasesViewBase.ts:

   const savedState = this.getEphemeralState();    // collapsedGroups: []  — captured BEFORE render
   try { await this.render(); }                    // seeds every group key
   finally { this.setEphemeralState(savedState); } // writes [] back over the seed

3. That render seeds the collapse default through initializeCollapseStateForSnapshot and paints the DOM all-collapsed.

4. The finally replaces collapsedGroups with the stale empty array and does not re-render — so the DOM shows collapsed groups while the view's state says nothing is collapsed.

5. The wipe is permanent: re-seeding is gated on initializedPrimaryGroupKeys, which already holds every key, so initializeCollapseStateForSnapshot never seeds again.

6. handleGroupToggle then reads collapsedGroups.has(key) === false and collapses the clicked group. The re-render expands all the others.

Fix

Restore collapse state from ephemeral state only before the view has built its first grouping snapshot; afterwards the view's own sets are authoritative.

hasInitializedCollapseState() and restoreCollapsedStateFromEphemeral() are extracted so the new guard is visible in review — the moved block is otherwise unchanged.

Tests

Two regression tests in tests/unit/ui/TaskListView.groupCollapse.test.ts replay the ordering the render wrapper actually produces (seed, then restore a pre-render snapshot): one asserts the collapse default survives it, one asserts a toggle then expands only the clicked group.

The suite already covered the opposite, safe ordering (restore-then-seed). The ordering production actually produces was untested, which is how this shipped.

Verification

• TaskListView.groupCollapse.test.ts: 9/9 pass — 2 of them fail on the current base without the fix, with exactly the reported symptom.
• Full suite: 3872 pass. The 17 failures across 7 suites are pre-existing on this base, verified by re-running them on an unmodified checkout.
• tsc --noEmit and eslint clean.
• Manually verified in a test vault with a full Obsidian restart: a chevron click now expands that group and leaves the others collapsed.

Known trade-off

If Obsidian ever calls setEphemeralState after the view's first render, the collapse portion of that payload is now ignored. The only observed post-render caller today is the render wrapper's own save/restore round trip.

Note on the broader design

The underlying coupling remains: get/setEphemeralState serves both Obsidian's cross-reload persistence and an intra-render scroll round trip, so correctness depends on call ordering relative to render(). Separating those concerns in BasesViewBase would eliminate the whole class of bug, but it touches KanbanView and CalendarView, which are not affected today. Deliberately left out of this change so the fix stays small and reviewable.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud