apps/web/src/store · scn-chat · Tangled

ATProto-based AI Assistant Chat interface.

scn-chat apps web src store

12 files

at admin-config-export

· The web app's message records are typed as the lexicon's MessageRecord, and a conversation's info as InfoRecord, from the local copy, which holds only records the server validated, through BranchMessage to the message, status, details, part, and tool views, so their reads need no casts. src/shared/message.ts holds what a status means, isPending and isFinished, which counts a status another client wrote that this app doesn't know as neither, along with a message's parts, whether it is encrypted, and who wrote it, in place of the checks written out in the message view, the message actions, the chat, the reply follower, and tool status. Tests build records with messageRecord in tests/helpers/records.ts, and the status rules are tested once. · 2w ago

The browser store's seam has a second adapter. The worker exposes every StoreCore method through one guard in store/calls.ts, which fails while another tab holds the store and reports an ended session, rather than restating each method, and StoreClient holds them as calls rather than worker. testStore in tests/helpers/store.ts runs the same logic and guard over better-sqlite3 with a fake server API, and the component tests that built their own store, for the conversation, chat list, app, chat, reply follower, settings, and the store's hooks, use it, so they go through the real reads, syncs, and change events. The chat list's search tests check the list is visible again rather than only present, since it stays mounted while hidden.

The browser store's seam has a second adapter. The worker exposes every StoreCore method through one guard in store/calls.ts, which fails while another tab holds the store and reports an ended session, rather than restating each method, and StoreClient holds them as calls rather than worker. testStore in tests/helpers/store.ts runs the same logic and guard over better-sqlite3 with a fake server API, and the component tests that built their own store, for the conversation, chat list, app, chat, reply follower, settings, and the store's hooks, use it, so they go through the real reads, syncs, and change events. The chat list's search tests check the list is visible again rather than only present, since it stays mounted while hidden.

The web app's message records are typed as the lexicon's MessageRecord, and a conversation's info as InfoRecord, from the local copy, which holds only records the server validated, through BranchMessage to the message, status, details, part, and tool views, so their reads need no casts. src/shared/message.ts holds what a status means, isPending and isFinished, which counts a status another client wrote that this app doesn't know as neither, along with a message's parts, whether it is encrypted, and who wrote it, in place of the checks written out in the message view, the message actions, the chat, the reply follower, and tool status. Tests build records with messageRecord in tests/helpers/records.ts, and the status rules are tested once.

Implement initial buildout of core features.

Crash and privacy fixes, request validation, login CSRF, SSRF guard, handover race, and cleanup.

Group the web app's code by feature. Each folder in src/features (auth, chat-list, conversation, sharing, models, settings, admin) holds that feature's pages, layouts included, components, hooks, lib, and queries, and the routes stay thin, rendering a feature's page. Page files are named after the component they export. The query factories split from src/queries.ts into each feature's queries.ts, leaving staleTime in src/shared, which also holds the API client, errors, search params, and the schema forms that admin and settings share. inheritedModel moves from the models module to the conversation's branch module, so models no longer depends on the conversation. Tests mirror the new tree, and the specs, the architecture doc, and CLAUDE.md name the new paths.

Crash and privacy fixes, request validation, login CSRF, SSRF guard, handover race, and cleanup.

The browser store's seam has a second adapter. The worker exposes every StoreCore method through one guard in store/calls.ts, which fails while another tab holds the store and reports an ended session, rather than restating each method, and StoreClient holds them as calls rather than worker. testStore in tests/helpers/store.ts runs the same logic and guard over better-sqlite3 with a fake server API, and the component tests that built their own store, for the conversation, chat list, app, chat, reply follower, settings, and the store's hooks, use it, so they go through the real reads, syncs, and change events. The chat list's search tests check the list is visible again rather than only present, since it stays mounted while hidden.

The chat list loads 50 chats at a time, newest first, and the next page as the end of the list nears, with three skeleton rows while it comes. The browser store pages by when a chat was updated and its key, so a chat moving to the top between pages is neither shown twice nor skipped, on a new index created on open when missing, so no one downloads their chats again. Given a tag, it pages through only that tag's chats, and the tags' counts and each chat's newest reply, for the new-reply marks, come from the store across every chat rather than the rows loaded, so a chat on a later page isn't marked new when it arrives. A change in the store refetches the pages already loaded, so a scrolled list keeps its place.

Port the chat sidebar from design-reference. The server answers GET /api/me/profile with the display name and Bluesky's CDN avatar thumbnail, read from the PDS on each request, and the browser store lists each chat's pending reply and newest complete reply and records when the index last synced. The sidebar puts New chat beside a search toggle, the tags as a folding filter, the chats under date headings with a dot for a reply in progress or one not yet seen on this device, a menu on each to rename, tag, or delete it in place, search results grouped by chat with their Markdown inline, and the account at the foot with a sync dot and a menu of where the chats live, their sync, Settings, Admin, and Sign out. New chat still creates the chat until the empty composer arrives.

Implement initial buildout of core features.

The browser store's seam has a second adapter. The worker exposes every StoreCore method through one guard in store/calls.ts, which fails while another tab holds the store and reports an ended session, rather than restating each method, and StoreClient holds them as calls rather than worker. testStore in tests/helpers/store.ts runs the same logic and guard over better-sqlite3 with a fake server API, and the component tests that built their own store, for the conversation, chat list, app, chat, reply follower, settings, and the store's hooks, use it, so they go through the real reads, syncs, and change events. The chat list's search tests check the list is visible again rather than only present, since it stays mounted while hidden.