LiveStash is not designed to stash megabytes of state. If a LiveView process holds megabytes of assigns, there are likely larger architectural issues at play. For typical, lightweight assigns, the ETS read/update/write cycle is negligible. That said, we aren’t ignoring the performance aspect. We are aware this read/update/write cycle could become a bottleneck under specific loads, and we already have ideas on how to optimize it in future releases. For this v0.1.0 we are prioritizing validation of the concept.
This is exactly why we designed an explicit API. We give developers full control over what and when gets stashed. It is the developer’s responsibility to manage their state logically. If they choose to only stash :k3, they only get :k3 back. We prefer giving them this explicit control over forcing a “save all or nothing” approach under the hood.
If you have a concrete implementation in mind that addresses these concerns without sacrificing explicit control, PRs are more than welcome!
Half true. If a node fully crashes, the state is indeed lost. However, if a user simply reconnects to a different node, it works fine. We handle this by using :erpc to fetch the stashed state from the original node. We literally have a working multi-node example demonstrating this exact scenario in the repo.
provide a stash_all/1 api to stash everything in the set. better yet, somehow hook into the handle_event callback and call stash_all at the end of every handle_* cycle automatically.
