4 ms·

LiveView is super exciting and extremely productive developer experience. One thing that I hope future versions can help address is what I call the "elevator" p

LiveView is super exciting and extremely productive developer experience. One thing that I hope future versions can help address is what I call the "elevator" problem, in that if I'm using a LiveView app on an elevator (or in my case at Costco), it becomes unusable as the connection gets too flakey. While I get offline support will never happen, maybe better support for unreliable connections would be fantastic, though I get how that could be against the ethos of what LiveView is trying to do.

Cyph0n 2y ago
Genuine question: wouldn’t server-based frontend JS apps be susceptible to the same issue? Of course, if your JS app isn’t server-based and can run non-trivial logic on the client, then it’s going to work better than a LiveView app.
- CharlieDigital 2y ago
  You can use a JS service worker and local storage. This is how Firestore works, for example
  - arcanemachiner 2y ago
    Someone made a PoC app (todo list) that integrates LiveView with offline support and conflict resolution via CRDTs. https://liveview-svelte-pwa.fly.dev/ https://liveview-svelte-pwa.fly.dev/ It's a toy app obviously, but I was impressed with the potential of so many technologies being integrated with each other (It even has Svelte in the mix via LiveSvelte[1]). [1] https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
    - mike1o1 2y ago
      Agreed! I am hopeful that future versions might help address these challenges at the framework level. It’s the Achilles heel to LiveView. As soon as the connection gets unreliable or has some latency a lot of the magic goes away. Most of the time the productivity boost from working in LiveView more than makes up for it, though.
- mike1o1 2y ago
  Yes it would, it’s just not as noticeable in my experience. For example, I have a Todo app with my shopping list. Every time I unlock my phone to look at it, I need to wait for the socket to reconnect. Either I lost it due to poor reception, or my mobile browser killed the socket connection (but not the tab process). I don’t really have that with a traditional SPA, since the view is “dead”. Of course, interactions might be slow, but I can at least still browse the data already on the screen.
evnp 2y ago
I haven't had bandwidth to explore the implementation deeply yet, but this seems almost too relevant: "Working in Elevators: Offline-Enabled Realtime Apps with LiveView, Svelte, & Y.js" https://liveview-svelte-pwa.fly.dev/ https://liveview-svelte-pwa.fly.dev/
elcritch 2y ago
There’s more support for doing some various JS events locally without waiting for the server. It also improves the offline connection support as well AFAICT. The `JS.push` stuff was new to me and makes it easy to do simple functionality like switching tabs without needing to wait for the server, or for the server to keep that state at all.
Muromec 2y ago
>While I get offline support will never happen You can in theory compile part of your elixir app to wasm, run it on the client, threat is a just another process and mutate the state of live view from there. It's a question of fitting all the pieces of tooling together
samgaw 2y ago
I'm grossly over simplifying but I've always thought a cut down version of Replicache[1] functionality would be an amazing logical progression for LiveView. With Phoenix.Component[2] introducing attributes it's perhaps closer to being feasible. [1] https://replicache.dev https://replicache.dev [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.h...

Cyph0n 2y ago

Genuine question: wouldn’t server-based frontend JS apps be susceptible to the same issue? Of course, if your JS app isn’t server-based and can run non-trivial logic on the client, then it’s going to work better than a LiveView app.

CharlieDigital 2y ago
You can use a JS service worker and local storage. This is how Firestore works, for example
- arcanemachiner 2y ago
  Someone made a PoC app (todo list) that integrates LiveView with offline support and conflict resolution via CRDTs. https://liveview-svelte-pwa.fly.dev/ https://liveview-svelte-pwa.fly.dev/ It's a toy app obviously, but I was impressed with the potential of so many technologies being integrated with each other (It even has Svelte in the mix via LiveSvelte[1]). [1] https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
  - mike1o1 2y ago
    Agreed! I am hopeful that future versions might help address these challenges at the framework level. It’s the Achilles heel to LiveView. As soon as the connection gets unreliable or has some latency a lot of the magic goes away. Most of the time the productivity boost from working in LiveView more than makes up for it, though.
mike1o1 2y ago
Yes it would, it’s just not as noticeable in my experience. For example, I have a Todo app with my shopping list. Every time I unlock my phone to look at it, I need to wait for the socket to reconnect. Either I lost it due to poor reception, or my mobile browser killed the socket connection (but not the tab process). I don’t really have that with a traditional SPA, since the view is “dead”. Of course, interactions might be slow, but I can at least still browse the data already on the screen.

evnp 2y ago

I haven't had bandwidth to explore the implementation deeply yet, but this seems almost too relevant: "Working in Elevators: Offline-Enabled Realtime Apps with LiveView, Svelte, & Y.js" https://liveview-svelte-pwa.fly.dev/ https://liveview-svelte-pwa.fly.dev/

elcritch 2y ago

There’s more support for doing some various JS events locally without waiting for the server. It also improves the offline connection support as well AFAICT. The `JS.push` stuff was new to me and makes it easy to do simple functionality like switching tabs without needing to wait for the server, or for the server to keep that state at all.

Muromec 2y ago

>While I get offline support will never happen You can in theory compile part of your elixir app to wasm, run it on the client, threat is a just another process and mutate the state of live view from there. It's a question of fitting all the pieces of tooling together

samgaw 2y ago

I'm grossly over simplifying but I've always thought a cut down version of Replicache[1] functionality would be an amazing logical progression for LiveView. With Phoenix.Component[2] introducing attributes it's perhaps closer to being feasible. [1] https://replicache.dev https://replicache.dev [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.h...