I’m gonna keep this as brief as possible. For reference, the starting point of this discussion is https://vercel.slack.com/archives/C050WU03V3N/p1747848130955979.
getChat(id).messages is a signal, anyone anywhere can just call getChat(id).messages and have it be reactive when it's updated, no subscriber / event system requireduseSyncExternalStore's update method to tell React to invalidate the data for a specific chat. (:old-man-yells-at-rules-of-hooks: or something)ChatStore. How? A StateManager. The StateManager is basically Readonly<Chat> plus methods to update the chat properties — each implementing library can create a StateManager that is then used for that library’s ChatStore. I initially toyed around with some sort of abstract class architecture but the best version I could come up with was actually just an argument to the constructor of ChatStore.Here’s what it looks like in practice:
It’s a little bit of boilerplate, but it pays huge dividends in the simplicity of implementing any given framework: The framework declares a StateManager and its own extension of ChatStore, and then the framework’s hook (useChat, Chat, whatever) just proxies getChat(id).property using getters and setters.
Here’s the PR implementing this pattern (ignore the examples, they’re just updating imports):

Okay, okay, Svelte is working now — and there’s a clear and simple path for Vue and Solid support. But… don’t kill me, okay?
I think this library is overcomplicating what Svelte needs. Let me lead with an example — the ideal API for Svelte is:
<script lang="ts">
const chat = new Chat({ id, messages, ...rest });
</script>
…where Chat is basically a single-member ChatStore. (Basically, the arguments to new Chat should be roughly the union of the arguments supplied to useChat and ChatStore).
To draw a little more of this owl, here’s how a 100% complete, SSR-compatible, client-hydrated Svelte app would look:
/[id]/+layout.server.ts