- Is offline support for LiveView features anywhere in the pipeline for the Pheonix core team?
- Is there somewhere discussions around this are ongoing? I’d love to be part of it.
LiveView will never have offline support. It’s not because no one wants to do it, it’s because way LiveView works supporting offline is impossible. If you need to have offline support you need to use different technology.
Yeah as @wanton7 notes, LiveView is a serverside rendering technology. If the server isn’t available, rendering can’t happen.
Thank you for your responses.
I understand that at the moment, that’s the case- LiveView is strictly a serverside rendering technology.
Whether or not it plans to stay that way is what I wish to know.
Prior to LiveView, taking advantage of Channels with your favourite client-side technology seemed to be how far we could push the edge. Then LiveView happened. Now we don’t need a separate technology for that anymore.
I can imagine a path where the client-side state is maintained by the framework (Phoenix/LiveView) just like reinitiating the stateful connection is. It might be some baked-in JS functionality, but that’s up for discussion.
So, the question is whether that’s currently in consideration or it was and has been discarded.
It’s not strictly server side. You can’t just do offline LiveView web apps. There is this new project GitHub - elixir-desktop/desktop: Elixir library to write Windows, macOS, Linux, Android apps with OTP24 & Phoenix.LiveView that allows you to use LiveView to create mobile and desktop apps. But for strictly web browser based UI you need to have WebSocket connection connected to server for everything to work.
LiveView itself will probably never support client-only directly.
However, there are two developments in this space which might open up interesting possibilities in the future:
Thank you for clearing about being strictly server-side. You’re right about that.
But my question is still not answered.
I’m aware of Elixir-desktop and I follow its progress constantly. In fact, its example todo app illustrates what I’m curious about, albeit in a slightly different domain.
The todo app runs offline (desktop/mobile in this case) and manages its local state successfully.
Imagine the fictitious app developer adding a Phoenix backend to allow users to synchronize their todos across devices.
Can the server-side state be accessible to the app via WebSockets while the local copy takes over when there’s no connection, with both syncing when the connection is restored?
Returning to the web-browser based UI, the features I think are missing for LiveView to support the behaviour I described are:
These are the things that I’m wondering if they’re in the pipeline.
The decision on which tool to use is of course up for discussion.
If the concept is being considered actively in the first place is what I don’t know.
Thank you for your response.
A very clear answer.
Front-end capabilities being “batteries-included” with Phoenix would be great though if it happens in the future.
It would transit Phoenix from being an “Elixir Web Framework” to simply being a “Web Framework”
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.
I hadn’t considered this.
A quick Google search led me here: Saving and Restoring LiveView State · Fly
Any other helpful resources will be appreciated.
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.
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)
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.
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.
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.
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?
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.