Client-side UI message state

[cpsievert]

Summary

Moves UI message state ownership to the React client. After each completed message (stream end or non-streamed), the React component calls setInputValue with {role, content, content_type}. The Python server accumulates these into a reactive list powering messages(). Bookmark save/restore for UI messages also shifts: save reads from the server's accumulated list directly (no client round-trip), and restore sends a restore_messages reducer action to bulk-load messages on the client.

What's in here

JS (commits 1–3):

• setInputValue called on message completion (message action and chunk_end)
• restore_messages reducer action for bookmark restore
• Streaming content tracked imperatively via streamingRef (fixes stale React state from batched updates)
• Removed dead shinyChatBookmarkSave client protocol

Python (commit 4):

• messages() reads from _messages_list (accumulated from client input values via @reactive.event)
• Bookmark save reads _messages_list() directly; restore re-sends HTML deps via render_deps then dispatches restore_messages
• Removed StoredMessage, TransformedMessage, _store_message, _transform_message, _needs_transform, _current_stream_deps
• transform_user/transform_assistant params on messages() are now deprecated no-ops
• Transform tests updated to reflect new behavior

Why this is useful

• R users get reactive message access for free. The client pushing setInputValue on each message means R can read session$input[[paste0(id, "_message")]] without building a parallel server-side accumulation system. This was the primary motivation.
• Less code. Removes ~500 lines net, mostly the StoredMessage/TransformedMessage machinery and associated tests. Simplifies append_message, _append_message_chunk, and bookmark save/restore.
• Cleaner separation. The client owns what it displays; the server reads back the results.

Honest downsides

1. messages() is no longer synchronously consistent after append_message(). Previously, messages() was updated immediately when append_message was called. Now there's a round-trip delay (server → client → setInputValue → server). The dominant on_user_submit → messages() pattern isn't affected (the user message already round-tripped before the callback fires), but any code that appends and immediately reads in the same context would see stale data.

2. System messages are silently dropped from messages(). The old code stored system-role messages server-side even though they weren't sent to the client. Now the only path into _messages_list is the client round-trip, so system messages never appear in messages().

3. clear_messages() has a theoretical race. In-flight setInputValue calls sent before the client receives the clear action could re-add messages to _messages_list.

4. Server depends on client correctness. If the JS fails or setInputValue doesn't fire, messages() would be incomplete. The old approach had the server as its own source of truth.

5. Transform behavior changed. messages() now returns the transformed content (what the client echoes back) rather than the pre-transform content. This only affects the deprecated transform feature.

Open question

Most of the code complexity on main comes from the transform machinery (TransformedMessage, content_client/content_server, etc.), not from server-side message accumulation itself. If we stripped out transforms (they're deprecated) and kept server-side storage, _store_message would be ~3 lines. That would preserve synchronous consistency and server-side robustness while still getting most of the simplification. The JS changes (setInputValue on completion, restore_messages action) are valuable either way — R benefits regardless.

Whether the full client-ownership approach is worth the tradeoffs above, or whether a hybrid (Python keeps its own state, R reads from input values) is better, is worth discussing before merging.

Test plan

• JS: 264/264 tests pass, lint clean
• Python: 59/59 tests pass (29 unit + 30 Playwright)
• Bookmark save/restore works (including HTML deps)
• Streaming messages accumulate correctly
• Module-namespaced chat IDs work (hyphenated IDs)
• Transform tests updated for new behavior
• Manual testing with a real LLM chat app

🤖 Generated with Claude Code