Keeping state in the browser is already supported. You keep state in the query string or pass state from browser in LiveSocket’s params when it connects. You should do it anyway because WebSocket connection can disconnect any time and when you reconnect you need to recover important state like open panels, active tab and on. LiveView forms already support this recovery.
wanton7
3
kingdomcoder
I hadn’t considered this.
A quick Google search led me here: Saving and Restoring LiveView State · The Phoenix Files
It’s interesting.
Any other helpful resources will be appreciated.
1
josefrichter
Just to understand, why would you want to do all this in elixir/phoenix in the first place? I feel like you choose elixir/phoenix for apps where the server is a crucial component - i.e. you are basically doing some operations on a centralized database somewhere.
As opposed to predominantly server side apps like google docs, where the server part is, in a sense, mostly about backup/sync. Why not use javascript for this type of apps?
0
kingdomcoder
Team size/dynamics basically @josefrichter
Choosing to use JS means:
A. Getting a JS developer (S/he is unable to contribute to the Elixir codebase)
B. Training Elixir developers to be proficient in JS (Longer time to market)
C. Getting JS + Elixir developers (Pricier option)
2
derek-zhou
Frankly speaking, I have never seen one web application that can smoothly transition between online and offline states and works great in both states. If I were offline, I’d rather read a book.
8
wanton7
I don’t think there are that many resources about LiveView state management except that one. I’ve only used LiveView in my one of hobby project and I had same questions as you how to store state in the browse and had to find out everything myself. I think there should be official LiveView documentation for this explaining how you can build LiveView projects that can handle WebSocket reconnects and store state in browser for next visit etc.
2
kingdomcoder
That’s both funny and true.
Our product’s target users won’t always have great wifi. That’s why it’s important.
I think the Elixir community is well-positioned to solve this.
I hope we can come up with something someday soon.
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I don’t really see this as true. A key part of the Elixir / Erlang experience is the BEAM, and all of the proposed answers to running in someone’s browser offline involve not-the-BEAM.
I’m not trying to bash your interest here, but I do think it’s important to have realistic expectations of where these Elixir projects are headed. Offline support is an explicit non-goal from the LiveView core team. Offline versions of the BEAM (or alternative backends) are experimental at best.
The closest would be an electron style thing that bundles the BEAM and a browser into a full desktop app. This is technically offline in that it doesn’t require the internet. Maybe that works for your use case?
3
kingdomcoder
The ease of communication between BEAM nodes is what I hope can be extended to clients.
It’s hard to find something that rivals that in other ecosystems.
Perhaps I need to understand the limitations of the BEAM more clearly.
2
josefrichter
what you have in mind is something like lumen being downloaded and run on client side, and then connecting to other “nodes” running on other clients? sort of peer to peer network of beam nodes? decentralized “backend” apps? 
talking specifically about liveview, I sounds to me it’s going in the exact opposite direction than you are wishing for - you want thicker client, liveview promises to have some of the cool features of thick clients with actually super thin (almost none) client, doesn’t it?
1