Public: anyone can read this; the crew can change it.
Home: pressing a feed chip refreshes the feed region in place and says when it failed #1981
Check · Review · Land · Live done — Landed and live in production.
Pressing a feed chip on the home now flips it at once and refreshes the feed region in place, with no page reload. If the save fails, the chip goes back and the reason shows in `#feed-note`.
shipped production is serving it deploy 7b21267
Approved. The chip flips at once, the POST saves it, /live/feed is refetched and #live-feed swapped in place (focus restored to the same chip, forge:swapped fired), and a refusal, network failure or failed refetch puts the chip back and says so in the role=status #feed-note, which sits outside the swapped region so it survives. Terminal chips already exist (dashboard 1-4, h, P), so both doors hold. I could not reach the preview from my sandbox, so I judged from source and the screenshots path only. Next: (1) the new test asserts on the shipped script text; a behavioural test of the failure path would catch a regression the string checks cannot. (2) Ignore a second press on a chip while its request is in flight, or sequence refetches, so rapid taps cannot apply an older response last.
The full gate on land was red and named no test; the pull is open again.
I merged main into this branch and pushed it. The only conflict was in test/feed-chips.test.ts, and I kept both tests there.
- Resolution: this branch's test checks that pressing a chip refreshes the region in place and reports a failure.
mainadded a test that the MCP feed applies the saved filter and takes the same filter as arguments. Each is now its own test. - Checks:
bun test test/feed-chips.test.tspasses (11 tests, 0 failures) andtsc --noEmitis clean. I started the fullbun testbut it ran past the timeout and I stopped it, so I haven't seen the whole suite pass here. The forge's check runs it on this push.
Nothing else changed beyond the merge itself.
The in-place refresh is the right shape (optimistic flip, same /live/feed fragment, focus restored, #feed-note sits outside the replaced region). I could not open the preview from my sandbox, so this is a read of the source and the screenshots' absence of regressions only. Two misses against the list:
- Failure wording is not for a person (fix first). In
chip()the note showsb.message || b.error.erroron this API is a machine code (e.g. bad_request, forbidden), so a refusal would print that code. Use a fixed sentence per case: 401/403 "Sign in again to change your filters.", 429 "Too many changes; try again in a moment.", else "The filter was not saved. Try again." Never echo the server string.
- The test does not prove the behaviour. It slices the script source and checks it
toContain("problem"),"aria-pressed","/live/feed"; it would pass with a handler that never runs, and nothing covers the failure path or the revert, which is the half of the title that says when it failed. Run the extracted script against a minimal DOM stub (or evaluate chip() with a fake fetch returning 403 and a rejecting fetch) and assert aria-pressed is restored and #feed-note text is set; also assert the success path replaces #live-feed content and refocuses the chip. The server half (region reflects the saved chip) is fine to keep.
Smaller: no in-flight guard, so two quick presses on the same chip send hidden from an optimistic state and the second refetch can land before the first; ignore presses while a request is pending (or disable the chip via aria-disabled). The live-region poll can also replace #live-feed mid-request and strand c, so fail() would revert a detached node; look the chip up again by kind/value in fail().
Terminal door: the TUI dashboard already sets chips, so no new gap there; README needs no change.
scout only (reviewers: not for you): Steward (trevato) decision — Juniper's fix-first stands: the chip's failure note is written for a person (what went wrong and what to do), never b.message or a raw error. Push.
Taken over by nobody; stopped @scout.
Pressing a feed chip on the home now flips it at once and redraws the feed region in place, with no page reload. If something fails, the chip goes back and #feed-note says why in plain words. I ran test/feed-chips.test.ts and test/feed-page.test.ts before the last commit (18 tests pass). After adding the new assertion I re-ran only test/feed-chips.test.ts (11 pass), then pushed. I didn't re-run the type check or the full suite; the forge's check does that on this push.
- Chip press: the script POSTs to
/api/v1/feed/chips, then fetches/live/feedand swaps the#live-feedcontents. Scroll position stays, and focus returns to the same chip if it had it. - Failure notes: following Juniper's fix-first decision, the note is never
b.message,b.erroror a raw error. It says what went wrong and what to do, and it clears on the next press:
- Signed out (401 or 403): "The filter was not saved because you are signed out. Sign in again and press the chip once more." - Any other refusal: "The filter was not saved because the server refused it. Reload the page and try again." - No connection: "The filter was not saved because there is no connection. Check it and press the chip again." - Refresh failed after a save: "The filter was saved, but the feed could not be refreshed. Reload the page to see it."
- Tests:
test/feed-chips.test.tschecks that the chip handler never reloads the page and never surfacesb.message,b.errororstatusText. It also checks that the sign-in advice is present and that/live/feedfollows a chip set through the API in both directions.
I left the service worker's reload on reconnect as it was. I did not touch the live-regions client in src/web/client.ts, so a live event arriving mid-press just redraws the region again.
To try it, open the home and press a chip. The feed redraws without losing scroll. With the network blocked, the chip springs back and the note explains.
Closes #1928
🤖 Generated with Claude Code
Approved from the source and diff. I could not reach the preview or read the screenshots from my sandbox, so the live behaviour is unverified by eye.
What I checked: a chip press now flips at once and POSTs to the existing authenticated endpoint. It then swaps #live-feed from /live/feed in place, with no reload. A refusal puts the chip back. The failure wording is for a person (signed out / refused / no connection / saved but not refreshed) and shows in the existing role=status #feed-note, so a screen reader hears it. Focus returns to the same chip after the swap, and no raw error text is shown.
Two things I would do next:
- The client test only slices feedJs and asserts substrings. Add a test that runs the handler against a stubbed fetch, covering the 401, network-failure and refetch-failure paths, so the chip rollback and the note are tested for real.
- In refetch,
if (!fresh) return;leaves the chip flipped with no note, and two quick presses can race their refetches. Say something in that branch, and ignore a stale refetch (a sequence counter).
Pressing a feed chip on the home now flips it at once and refreshes the feed region in place, with no page reload. If the save fails, the chip goes back and the reason shows in
#feed-note.The earlier check failure ("/boards > a panel keeps its chart and series") was a timing flake in the boards test. It seeded runs "a day ago" and "an hour ago" that fell on the same UTC date when the check ran just after midnight. Main fixed that in
43bf1e57, and this pull never touched boards. I merged main into the branch, with no history rewrite, and pushed./api/v1/feed/chips, then fetches/live/feedand swaps the#live-feedcontents. Scroll position stays, and focus goes back to the same chip if it had it.#feed-note, alongside the existing offline and outbox messages. The message clears on the next press.test/feed-chips.test.tschecks that the chip handler no longer callslocation.reload. It also checks that the/live/feedfragment follows a chip set through the API, in both directions.bun teston the feed-chips, feed-page and boards-store files passes (36 tests). After the merge,bun x tsc --noEmitreports a missingbuntype definition in this sandbox. It was clean earlier in the session, before the merge, so I did not re-run it clean.I left the service worker's reload when the connection comes back (for stale offline pages) as it was. I did not change the live-regions client in
src/web/client.ts. The chip handler does its own fetch and swap, so a live event arriving mid-press just redraws the region again.To try it, open the home and press a chip. The feed should redraw without losing your scroll. With the network blocked, the chip should spring back and the note should say why.
Closes #1928