Accessing entire `state` value from the client?
From what I can gather, there doesn't actually seem to be a
state property exposed on any of the clients.
Am I correct in that understanding or have I missed something? Was this something intended to be implemented?
https://rivetkit.org/clients/react#:~:text=state%3A%20Current%20actor%20state%20(if%20available)
It might separately might be cool if that was a thing, but it could just be achieved with a getState() action I guess.3 Replies
I've just looked through the code and it does attempt to expose the state to client. https://github.com/rivet-gg/rivetkit/blob/main/packages/frameworks/react/src/mod.tsx && https://github.com/rivet-gg/rivetkit/blob/main/packages/frameworks/framework-base/lib/mod.ts#L145.
While this will work fine for small actors the size of the state may become a problem when it tracks state you don't want the client to be aware of and this may grow unpredictably. I currently use the state as a caching layer in one of my use cases.
I would really like to understand the motivation behind exposing the state to the client.
GitHub
rivetkit/packages/frameworks/react/src/mod.tsx at main · rivet-gg/...
🧰 Lightweight libraries for backends. Install one package, scale to production. Just a library, no SaaS. - rivet-gg/rivetkit
GitHub
rivetkit/packages/frameworks/framework-base/lib/mod.ts at main · r...
🧰 Lightweight libraries for backends. Install one package, scale to production. Just a library, no SaaS. - rivet-gg/rivetkit
Yeah I was working on the Svelte package which is the other reason why I wanted to confirm if it's expected or not.
I don't think
state is actually the state object you define in the actor here though, just the properties defined on ActorStateReference
https://github.com/rivet-gg/rivetkit/blob/main/packages/frameworks/framework-base/lib/mod.ts#L13C1-L69C2
But I might be missing somethingthe name here is misleading. this is just "state of the client" (e.g. existing connection to the actor), it doesn't expose internal state of the actor – that'd be a security & performance concern as it is designed right now
the reason we have a shared state between
useActor is so you can call useActor from multiple components and share the same underlying connection. this needs to be better documented.