Publish the active view from the shell, so both navs survive the back path

Conversation 0 Commits 3 Files Changed 11

+535 -65

3 Commits

Author	SHA1	Message	Date
logan	d347809e6e	docs: record the one statement of which view is active CI / e2e (push) Skipped CI / check (push) Skipped CI / check (pull_request) Successful in 2m29s Details CI / e2e (pull_request) Successful in 6m53s Details It belongs beside the two rules that already keep the history stack and the in-app back buttons agreeing, and for the same reason: a second component-local idea of where the user is, is how they came to disagree.	2026-08-19 17:00:39 -04:00
logan	a5ffcc22e3	test(e2e): assert the nav highlight, not the shell's own bookkeeping `back-navigation.spec.ts` covered exactly the journeys #72 breaks and was green throughout it, because every assertion in it was `data-active-view` — which the shell sets on every path including the back one, and which was the one thing already correct. The same trap `layout-overflow.spec.ts` set for #69: a spec named for the behaviour, measuring the plumbing. The assertions go here rather than in a second file, or the first would carry on passing vacuously. They are `aria-current="page"` through `getByRole`, which is the accessible fact — `.active` is a class and could be restyled without breaking anything real — and the role query resolves to whichever nav is in the accessibility tree at that viewport, so one helper covers the sidebar and the tab bar. Three of the four fail on the build before the fix. The fourth, the parent staying lit while a detail view is open, passed by accident and says so.	2026-08-19 17:00:39 -04:00
logan	f18691560d	fix(shell): publish the active view, so both navs follow the back path The nav components learned where the user was from the `navigate` CustomEvent, which only the outbound path dispatches: `popstate` calls `handleNavigate()` directly. So a back-navigation left both of them highlighting the view just left — desktop included, at any width, on any back across two primary views. Opening a detail view was the same cause wearing a different symptom: `app-sidebar` guarded on its own item list and kept its highlight, `bottom-nav` did not and lit nothing. It cannot be fixed by re-dispatching `navigate` — `index.ts` is that event's document listener, so that is an infinite loop, and "please go to X" is not the statement being made. `activeViewStore` is the shell saying "the active view is now X", once per navigation, `popstate` included; both navs read it through a controller and hold no `activeView` of their own. A store rather than an event because a component that mounts after a navigation still has to know: `bottom-nav`'s drawer builds its `app-sidebar` on open, and that copy had heard nothing at all, so the drawer opened on Home from any page in the app. Closes #72	2026-08-19 17:00:39 -04:00

Author

SHA1

Message

Date

logan

d347809e6e

docs: record the one statement of which view is active

CI / e2e (push) Skipped

CI / check (push) Skipped

CI / check (pull_request) Successful in 2m29s

Details

CI / e2e (pull_request) Successful in 6m53s

Details

It belongs beside the two rules that already keep the history stack and
the in-app back buttons agreeing, and for the same reason: a second
component-local idea of where the user is, is how they came to
disagree.

2026-08-19 17:00:39 -04:00

logan

a5ffcc22e3

test(e2e): assert the nav highlight, not the shell's own bookkeeping

`back-navigation.spec.ts` covered exactly the journeys #72 breaks and
was green throughout it, because every assertion in it was
`data-active-view` — which the shell sets on every path including the
back one, and which was the one thing already correct. The same trap
`layout-overflow.spec.ts` set for #69: a spec named for the behaviour,
measuring the plumbing.

The assertions go here rather than in a second file, or the first would
carry on passing vacuously. They are `aria-current="page"` through
`getByRole`, which is the accessible fact — `.active` is a class and
could be restyled without breaking anything real — and the role query
resolves to whichever nav is in the accessibility tree at that
viewport, so one helper covers the sidebar and the tab bar.

Three of the four fail on the build before the fix. The fourth, the
parent staying lit while a detail view is open, passed by accident and
says so.

2026-08-19 17:00:39 -04:00

logan

f18691560d

fix(shell): publish the active view, so both navs follow the back path

The nav components learned where the user was from the `navigate`
CustomEvent, which only the outbound path dispatches: `popstate` calls
`handleNavigate()` directly. So a back-navigation left both of them
highlighting the view just left — desktop included, at any width, on
any back across two primary views. Opening a detail view was the same
cause wearing a different symptom: `app-sidebar` guarded on its own
item list and kept its highlight, `bottom-nav` did not and lit nothing.

It cannot be fixed by re-dispatching `navigate` — `index.ts` is that
event's document listener, so that is an infinite loop, and "please go
to X" is not the statement being made. `activeViewStore` is the shell
saying "the active view is now X", once per navigation, `popstate`
included; both navs read it through a controller and hold no
`activeView` of their own.

A store rather than an event because a component that mounts *after* a
navigation still has to know: `bottom-nav`'s drawer builds its
`app-sidebar` on open, and that copy had heard nothing at all, so the
drawer opened on Home from any page in the app.

Closes #72

2026-08-19 17:00:39 -04:00

Publish the active view from the shell, so both navs survive the back path #141