derek-zhou
Idea: persist liveview state across reconnections
Liveview is nice with one small problem: With mobile, or on shaky network, there will be frequent dropped connections. Yes, Liveview reconnects from the client side automatically, but the state at the server side process is lost. Here is an idea:
- trap exit in liveview, and when
terminate/2is called, persist the full content of assigns somewhere. (database, flat file, etc), key off an opaque and unique id shared with the client side. - at mount, check to see if this unique id can be found in the persistent storage. If so, load the full content into assigns.
There will be some small wrinkles like versioning the saved data, periodic clean up the storage, etc. but it seems like everything should be doable. Any comments?
Most Liked
wanton7
Because there might be multiple servers behind one domain and you don’t know which one of those servers WebSocket connection connects that’s why client side state is used. If you have issues with lost state you are not properly storing important state to the client and using that state on reconnect to restore your views. Important state meaning open panels, select element values that are not stored anywhere expect client etc., state that is used to get you to the same view state you where before disconnect but excluding things you can get from your databases. You could example store those open panels to the URL’s query string. You can also use LiveSocket’s params field to send data from client to server on reconnect.
sodapopcan
Fly did an article that uses client-side session storage for this purpose.
Otherwise, my feeling is that whenever possible, state should always be recreateable via the db and more notably the URL—many neglect the latter. I’m even talking things like tabs that may already have the data loaded but hidden. Just giver ‘er a good ol’ window.history.pushState. But I will now step off my soapbox ![]()
wanton7
For game maybe you could create something similar to Microsoft Orleans Virtual actors with processes? I mean like start a GenServer for the game logic that keeps the state and then just pass reference id to that game process to the client and maybe put some info into database that user has access to that game into database or maybe encode it’s id into a JWT token? That game state could then live even in another server. So if you connect to server1 you could just message game state running on server2 where it was originally started. Then that game state could have timeout that makes it die after certain time passes after no keep alive messages. In this case you should only keep minimal game state information in LiveView’s process. Benefit from this is that you could even have multiple LiveViews connecting to same game.
For AI I think that highly depends on what kind of AI data how much. If it’s images you probably store it somewhere anyway and just provide a link.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









