IVR

Using sockets instead of LiveView

Hi all,

I’m in the early phases of developing a website and I’m hoping to go with Phoenix without any frontend frameworks. I’d like to use some of the LiveView features, however, I’m a little cautious about going all-in on LiveView. Ideally, I’d like to use regular controllers throughout my site, but I would want to embed live components in a number of places. However, I’m also considering using plain web sockets instead.

There are 2 reasons why I’d prefer to avoid using LiveView everywhere:

I just don’t need it in most places
I understand that it may require a slightly different approach in a few places – if so, then there’s just less documentation (other than the official docs) and I’ve heard some people have had problems with it (do not have any concrete examples)

As for integrating LiveView with regular components, I don’t think I fully understand how it would work. Correct me if I’m wrong, but I don’t think I’d be able to embed a live component into a static parent view, right? The entire page would need to be live. If I’m using live and static views side by side, would I run into problems with routing or anything else?

Finally, given my objectives, do you think it makes sense to go with:

Full LiveView app
Mix of regular controllers and LiveView (if this is what you’d recommend, then I’d appreciate suggestions on how to set this up – do I create a LiveView app inside of which I’d set up regular controllers or do I create a regular app where I’d create live stuff?)
Ditch LiveView altogether and just use sockets

If option 3 is not recommended, then I have another follow up question: now that we have LiveView, are there scenarios where you’d still use plain web sockets?

Many thanks!

11 comments

/phoenix #websockets #liveview

0 2001 11

2021-01-13 16:27:33 UTC

Most Liked

ityonemo

Regular controllers with a handful of live pages. This is the original way to use liveview and it’s still valid. You don’t have to go all-in on the SPA feel.

Post #1

aseigo

Echoing what some others have said to some degree, but adding a few points (hopefully! ) →

You make the decision per route in your site whether (and how) to use LiveView. I have a couple significant apps that mix and match as makes sense. I’ve even transitioned some ‘regular’ pages to LiveViews, and some LiveViews to ‘regular’ pages as requirements became clearer or evolved. It’s really flexible like that, and not a one-way-OR-the-other choice.

You also said you might just go with “plain (web)sockets”, well .. that’s what LiveView is, only with a well-defined lifecycle and efficient handling of DOM changes. So it takes a lot of the stuff-one-can-get-wrong off our shoulders.

That said, sometimes I’ve had to use the pushEvent /push_event functions to pass messages over the websocket that the LiveView uses in order to integrate with more complex / dynamic client-side JS libraries (such as Sortable and OpenLayers). That’s the same as “over a plain socket” at the end of the day, but only as needed (LiveView can handle the rest..)

So the choice between LiveView vs “just messages over the socket” also isn’t binary: you can do both at the same time. I certainly do!

Post #11

subbu

Creating your app with --live is better. It setups all the live helpers and all the machinery required to run both normal views and live_views. Wherever you need live_view you can do
<%= live_render(@conn, MyAppWeb.ThermostatLive) %>. And

# In the router
live "/thermostat", ThermostatLive, session: %{"extra_token" => "foo"}

# In a view
<%= live_render(@conn, MyAppWeb.ThermostatLive, session: %{"extra_token" => "foo"}) %>

You can embed live_views anywhere you want. I am doing embedded live_views too. They work perfectly fine. They take a bit of time to understand, but they work just fine. I recommend watching the Pragmatic Studio’s LiveView course. They are really nice and explain some tricky concepts nicely.

Post #3