yellowjacket

yonlu/yellowjacket

Fork 0

Author	SHA1	Message	Date
logan	f34777d3e4	docs: record the one statement of which view is active CI / check (push) Skipped CI / e2e (push) Skipped CI / check (pull_request) Successful in 2m35s Details CI / e2e (pull_request) Successful in 7m2s 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 16:45:58 -04:00
logan	fef8c8b7f6	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 16:45:58 -04:00
logan	9d65d9acdd	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 16:45:47 -04:00

Author

SHA1

Message

Date

logan

f34777d3e4

docs: record the one statement of which view is active

CI / check (push) Skipped

CI / e2e (push) Skipped

CI / check (pull_request) Successful in 2m35s

Details

CI / e2e (pull_request) Successful in 7m2s

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 16:45:58 -04:00

logan

fef8c8b7f6

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 16:45:58 -04:00

logan

9d65d9acdd

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 16:45:47 -04:00

Compare commits

Diff Content Not Available