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

ATProto-based AI Assistant Chat interface.

scn-chat apps web src features

7 folders

at admin-config-export

· Settings and admin forms keep Save disabled until the form differs from what was saved, and say "Unsaved changes" beside it until then. SaveBar reads this from its form's context, and a form that adds, such as Issue key or Add plugin, passes adds so it never says so. Leaving a page doesn't ask. Preferences now starts over from the stored record after a save, as the other forms do. · 1w ago

Settings and admin forms keep Save disabled until the form differs from what was saved, and say "Unsaved changes" beside it until then. SaveBar reads this from its form's context, and a form that adds, such as Issue key or Add plugin, passes adds so it never says so. Leaving a page doesn't ask. Preferences now starts over from the stored record after a save, as the other forms do.

Sign in's Continue reads "Signing in…" once it is clicked, and its arrow gives way to the button's spinner, since it is leaving for the PDS rather than waiting on something it was asked to do. Coming back with the browser's back button shows Continue and its arrow again. The web UI spec makes it the one busy button that changes its label, and the test checks the new label and that the spinner is its only icon.

Small settings, admin, and sidebar fixes. Renaming a chat from the sidebar won't save an empty title, which marked the chat user-titled and kept it from ever being titled automatically; EditForm takes required, and form.SubmitButton takes disabled. Secret fields use secretInput (autocomplete="new-password" and the password managers' ignore attributes), since a filled-in password would replace the saved secret, and model IDs, handles, base URLs, and slugs use literalInput, so phone keyboards don't capitalize or correct them; both live in shared/ui/controls.tsx. Removing a role member asks to confirm in place. Add user, Add member, Add model, and Create role return their mutation from onSubmit, so the button stays busy until it finishes and can't send twice, and a listed model can't be ticked twice while it is being added. Every settings and admin route has a staticData title, and pageTitle joins them deepest first, as "API keys · Settings · SCN Chat", with a page opened from a section taking that section's title.

The composer decides whether a message can be sent once, as canSend, which both disables Send and stops a submit, so a new reason not to send can't reach one and miss the other. Submitting still checks on its own for a send already on its way and for a running reply, whose Stop takes Send's place.

A change to the open conversation, such as a message arriving or a reply finishing, renders again only the messages it changed, rather than every message and its actions. BranchView gives each message's row only its record, which the local copy keeps the same object while unchanged, its place among its versions as numbers and the rkeys on either side, and functions that stay the same from render to render: useChat's stop and regenerate call the mutations' own stable functions, and useModels gives the same empty list until models arrive. The reply running at the end of the branch, whose Stop the composer offers instead, reaches the Stop actions through a RunningReply context rather than the operations every action gets, so a reply starting or finishing rerenders only those. The web UI spec says so, and a ConversationView test counts each message's renders as a reply finishes.

Settings and admin forms keep Save disabled until the form differs from what was saved, and say "Unsaved changes" beside it until then. SaveBar reads this from its form's context, and a form that adds, such as Issue key or Add plugin, passes adds so it never says so. Leaving a page doesn't ask. Preferences now starts over from the stored record after a save, as the other forms do.

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.