undefined | Better HN

0 pointsheipei6y ago0 comments

I've been watching Elixir/Phoenix/LiveView from the sidelines, reading just enough to salivate a little but still left with the feeling that my use-cases wouldn't be adequately covered by it. Which kind of SPAs wouldn't work well in LiveView? I'm working on an app in Ember right now where a lot of data is fetched by the client asynchronously and then either showed once its fetched or only when the user pushes a button. How would the latter be possible with LiveView? Can you push data to the client that's only show on client-side interaction? Do I still need a client->server->client roundtrip to toggle a "visible" flag to show said data? I just don't understand how "smart" the client side of LiveView is.

0 comments

3 comments · 3 top-level

dnautics6y ago

The spas that won't work are the ones that need to keep state while offline. Everything else works pretty fantastic, and arguably better than most spas which need to do heavyweight xhr Json or grpc calls, though if you can have a persistent grpc connection over websocket you might be competitive performance-wise.

ketzo6y ago

I'm honestly not sure. I would ask on the Phoenix [1] forums -- they're pretty active, including a lot of responses from Phoenix's creator, Chris Mccord.

[1] https://elixirforum.com/c/phoenix-forum

pythonaut_166y ago

The biggest "homerun" case for LiveView is all of the forms where you'd typically do server side rendering then add a bit of JavaScript for the few dynamic pieces you need. Think about what you might typically see in a Ruby on Rails app. Lots of Ruby generating the views, a bit of JavaScript for client-side whatever.

LiveView can be used for way more than that, but I think replacing "glue" JavaScript is the most slam-dunk case.

j / k navigate · click thread line to collapse