Skip to content

Tasks: remember the List/Board choice per project - #1704

Open
builtui wants to merge 1 commit into
get-bb:mainfrom
builtui:fix/tasks-remember-view
Open

Tasks: remember the List/Board choice per project#1704
builtui wants to merge 1 commit into
get-bb:mainfrom
builtui:fix/tasks-remember-view

Conversation

@builtui

@builtui builtui commented Aug 17, 2026

Copy link
Copy Markdown

Fixes #1702

Problem

The Tasks view mode lives only in the URL, and every route into a project pinned the list:

Route in Before
Sidebar project click current route's view, else "list"
Task breadcrumb hardcoded view: "list"
New project dialog hardcoded view: "list"
Bare <projectId> subPath (reload, deep link) parsed to "list"

So picking Board, opening a task, and coming back landed on the list — every time. The two neighbouring preferences already persist: sidebar collapsed state (shell/sidebar-preference.ts) and list filters/sort (views/list/list-preference.ts).

Change

A project route's view is now TaskViewMode | null, so "no view named" is distinct from "list". The shell resolves a null view through a new shell/view-preference.ts — the same client-local localStorage boundary the sidebar and list preferences use, so one client does not rewrite another client connected to the same bb server.

  • The topbar toggle is the only place a user picks a view, so navigating with an explicit view is what records the choice (done once in the shell's navigation wrapper).
  • The three routes that hardcoded "list" now name no view and let the preference answer.
  • A project opened for the first time follows the view most recently chosen anywhere, then the list — switching projects keeps the feel of the old carry-over behaviour instead of snapping back.
  • Storage handling mirrors list-preference.ts: unknown values are ignored, corrupt documents read as unset, and a document written by a newer client is left untouched rather than down-converted.

An unknown marker (?view=kanban) now resolves through the preference instead of silently meaning "list".

Tests

  • shell/view-preference.test.ts — fallback chain, per-project isolation, corrupt documents, future-version write refusal.
  • shell/shell.test.tsx — round-trips the marker-less project route; toggling Board then reopening the bare project URL renders the board; per-project choices stay apart while an unseen project follows the last one used; the sidebar navigates without pinning a view; toggling still works when storage rejects writes.

turbo run typecheck test --filter=bb-plugin-tasks: 36 test files pass, typecheck clean.

Notes

Client-local UI state only — no contract, RPC, CLI, or docs surface changes.

AGENT GENERATED: by Claude Opus 5

The view mode lived only in the URL, and every route into a project pinned
the list: the sidebar fell back to "list", the task breadcrumb and the New
project dialog hardcoded it, and a bare "<projectId>" subPath parsed to it.
Picking Board, opening a task, and coming back therefore landed on the list
again, every time.

A project route's view is now nullable — "no view named" is distinct from
"list" — and the shell resolves a null view through a new client-local
preference, the same localStorage boundary the sidebar and list preferences
already use so one client does not rewrite another client on the same bb
server. The topbar toggle is the only place a user picks a view, so
navigating with an explicit view is what records the choice.

Projects opened for the first time follow the view most recently chosen
anywhere, then the list; the routes that used to hardcode "list" now name no
view and let the preference answer.

Fixes get-bb#1702

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tasks: the List/Board choice is forgotten every time a project is reopened

1 participant