apps/web/src/parts/tools · scn-chat · Tangled

ATProto-based AI Assistant Chat interface.

scn-chat apps web src parts tools

3 folders · 3 files

at admin-config-export

pouriade.com · The chat list and its rows do less work, from an audit against React performance practice. Opening a search hides the chat list inside React's Activity rather than unmounting it, so closing the search brings the chats back as they were rather than mounting every row again. A chat row no longer holds three mutations: renaming and tagging are an EditChat card and deleting a DeleteChat card, each holding its own, so an idle row holds none, and cancelling a failed change clears its error with the card. Picking a tag keeps the rows shown until its chats arrive, rather than a skeleton between. The month headings of older chats come from two formatters made once, rather than one made for each chat on every change to the list. A reply's sources and a search's results take the fold's ref apart, so React Compiler compiles them rather than silently leaving them out. The conversation's rename, instructions, and sync call their mutations' own functions, so the header no longer renders with every state either passes through, and its jump outline is built only while the jump stack is open. The search spec says the list stays mounted, and the list test checks it is hidden. · 2w ago

A reply's tool calls show as what they did. A web search reads "Searched the web" with its query and opens onto its results, each its title linking to the page in a new tab, its site, and its snippet as plain text, or "No results." A page fetch reads "Read a page" with its address and opens onto the page's title and site, which of its characters the call read when there were more, and the text it read as plain text. The live line says "Searching the web…" and "Reading a page…", and a finished reply's steps are summed up as "Thought for 12s · Searched the web ×2 · Read a page". Each tool's entry in toolViews, in parts/tools/, gives its label, its activity, the glimpse of its input on its row, and its view, and a tool without one reads by its name with its input and output as before, which a view also falls back to for an error, output kept in a blob, or output it can't read. Each call has one status from toolStatus, running, done, error, or incomplete, which its badge, number, timer, and the live line all read, so calls made at once all show as running until their results arrive, where before only the last did, and a call cut off without its result says incomplete. Tool output stays text: no HTML, Markdown, images, or favicons, and links only to web pages. The tool views spec, split out of the extending spec, describes it, the plugin guide tells tool authors where a view goes, and the tests render replies through MessageView.

A reply's tool calls show as what they did. A web search reads "Searched the web" with its query and opens onto its results, each its title linking to the page in a new tab, its site, and its snippet as plain text, or "No results." A page fetch reads "Read a page" with its address and opens onto the page's title and site, which of its characters the call read when there were more, and the text it read as plain text. The live line says "Searching the web…" and "Reading a page…", and a finished reply's steps are summed up as "Thought for 12s · Searched the web ×2 · Read a page". Each tool's entry in toolViews, in parts/tools/, gives its label, its activity, the glimpse of its input on its row, and its view, and a tool without one reads by its name with its input and output as before, which a view also falls back to for an error, output kept in a blob, or output it can't read. Each call has one status from toolStatus, running, done, error, or incomplete, which its badge, number, timer, and the live line all read, so calls made at once all show as running until their results arrive, where before only the last did, and a call cut off without its result says incomplete. Tool output stays text: no HTML, Markdown, images, or favicons, and links only to web pages. The tool views spec, split out of the extending spec, describes it, the plugin guide tells tool authors where a view goes, and the tests render replies through MessageView.

The chat list and its rows do less work, from an audit against React performance practice. Opening a search hides the chat list inside React's Activity rather than unmounting it, so closing the search brings the chats back as they were rather than mounting every row again. A chat row no longer holds three mutations: renaming and tagging are an EditChat card and deleting a DeleteChat card, each holding its own, so an idle row holds none, and cancelling a failed change clears its error with the card. Picking a tag keeps the rows shown until its chats arrive, rather than a skeleton between. The month headings of older chats come from two formatters made once, rather than one made for each chat on every change to the list. A reply's sources and a search's results take the fold's ref apart, so React Compiler compiles them rather than silently leaving them out. The conversation's rename, instructions, and sync call their mutations' own functions, so the header no longer renders with every state either passes through, and its jump outline is built only while the jump stack is open. The search spec says the list stays mounted, and the list test checks it is hidden.

A reply's tool calls show as what they did. A web search reads "Searched the web" with its query and opens onto its results, each its title linking to the page in a new tab, its site, and its snippet as plain text, or "No results." A page fetch reads "Read a page" with its address and opens onto the page's title and site, which of its characters the call read when there were more, and the text it read as plain text. The live line says "Searching the web…" and "Reading a page…", and a finished reply's steps are summed up as "Thought for 12s · Searched the web ×2 · Read a page". Each tool's entry in toolViews, in parts/tools/, gives its label, its activity, the glimpse of its input on its row, and its view, and a tool without one reads by its name with its input and output as before, which a view also falls back to for an error, output kept in a blob, or output it can't read. Each call has one status from toolStatus, running, done, error, or incomplete, which its badge, number, timer, and the live line all read, so calls made at once all show as running until their results arrive, where before only the last did, and a call cut off without its result says incomplete. Tool output stays text: no HTML, Markdown, images, or favicons, and links only to web pages. The tool views spec, split out of the extending spec, describes it, the plugin guide tells tool authors where a view goes, and the tests render replies through MessageView.

A reply's tool calls show as what they did. A web search reads "Searched the web" with its query and opens onto its results, each its title linking to the page in a new tab, its site, and its snippet as plain text, or "No results." A page fetch reads "Read a page" with its address and opens onto the page's title and site, which of its characters the call read when there were more, and the text it read as plain text. The live line says "Searching the web…" and "Reading a page…", and a finished reply's steps are summed up as "Thought for 12s · Searched the web ×2 · Read a page". Each tool's entry in toolViews, in parts/tools/, gives its label, its activity, the glimpse of its input on its row, and its view, and a tool without one reads by its name with its input and output as before, which a view also falls back to for an error, output kept in a blob, or output it can't read. Each call has one status from toolStatus, running, done, error, or incomplete, which its badge, number, timer, and the live line all read, so calls made at once all show as running until their results arrive, where before only the last did, and a call cut off without its result says incomplete. Tool output stays text: no HTML, Markdown, images, or favicons, and links only to web pages. The tool views spec, split out of the extending spec, describes it, the plugin guide tells tool authors where a view goes, and the tests render replies through MessageView.

A reply's tool calls show as what they did. A web search reads "Searched the web" with its query and opens onto its results, each its title linking to the page in a new tab, its site, and its snippet as plain text, or "No results." A page fetch reads "Read a page" with its address and opens onto the page's title and site, which of its characters the call read when there were more, and the text it read as plain text. The live line says "Searching the web…" and "Reading a page…", and a finished reply's steps are summed up as "Thought for 12s · Searched the web ×2 · Read a page". Each tool's entry in toolViews, in parts/tools/, gives its label, its activity, the glimpse of its input on its row, and its view, and a tool without one reads by its name with its input and output as before, which a view also falls back to for an error, output kept in a blob, or output it can't read. Each call has one status from toolStatus, running, done, error, or incomplete, which its badge, number, timer, and the live line all read, so calls made at once all show as running until their results arrive, where before only the last did, and a call cut off without its result says incomplete. Tool output stays text: no HTML, Markdown, images, or favicons, and links only to web pages. The tool views spec, split out of the extending spec, describes it, the plugin guide tells tool authors where a view goes, and the tests render replies through MessageView.