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?
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.
Great, thanks! And how would that work? Should I just create a regular app (without --live) and then create live components that I can embed into regular views or would I create live pages?
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.
I’d create the project with --live, but just add controllers afterwards. Afaik the latest default generators do generate a liveview ready setup as well, but I’m not sure if things like the bootstrapped modal component are present there.
Liveview components always need to have a liveview parent. It however can be a liveview handling the whole page, but also can be one embedded within a static page.
Imho there are three parts here: Plain websockets, Phoenix Channels and Phoenix LiveView. With liveview custom channels become for the most part obsolete, like channels make bare websockets for the most part obsolete. There can still be niche use cases for doing multiple of those, but for the common case this should hold true.
The problem of us developers is that we tend to jump into the new shine thing without trying to grasp it correctly first, aka we learn as we go… I was like this in the begin of my career and that hurts more in the long term then it helps. We think we go fast, but we just take more time to complete the journey, then if we take the time to prepare for it.
That being said I strongly recommend you to first set some time aside and try to fully grasp first the technology, and for that @mikeclark provides us with an excellent free in-depth LiveView course, as recommended by @subbu while I was writing my reply:
Very good point! I have mixed feelings about this. To be honest with you, I spent the last 4 months or more learning the basics of web developments. I have a reasonable amount of professional programming experience (unrelated to the web) and I already had some knowledge of HTML/CSS/JS fundamentals, so I spent most of that time on a selection of backend and frontend frameworks. On the backend, I initially chose Django, then tried Phoenix and decided to stick with it. On the frontend, I mostly spent time with Vue (also tried a bit of React), but I realised that I may not actually need it and I really liked the idea of avoiding SPA complexities. While the time I spent may not seem like a lot, I got to the point where I felt like I understood the basics but I was still not at all confident applying them. I thought that to get over this barrier I should just start applying them and even if I screw up my first project then I’ll just start again. I’m still not sure what is the best approach to learn web technologies (or anything else for that matter), but I got a little fatigued from doing tutorials for months. I feel that even if I get burnt by making a bad choice early on in my project, I will still learn a lot from it and that’s the entire point of the whole exercise.
I overviewed the Pragmatic Studio course on LiveView and I thought it was great, but based on what I can recall, the course goes all-in with LiveView and in this thread, I wanted to compare the LiveView-centric approach with alternatives (e.g. integrating LiveView with traditional controllers or just using sockets).
Let me know if you have any other thoughts on this matter
Off-course I am not saying you should keep doing it for months, neither you need top be an expert.
I should have been clear in my point. The message I was trying to pass is that we shouldn’t just jump in and learn as we go, we should first understand the basics and the mechanics of it, by reading docs, a book or following some good course/workshop.
No matter what I am learning I always follow the method of doing it in the hard way, as I learned from the Python book with the same name. This consists in you doing all the exercises in the book, tutorial, course, etc. and then explain by your own words what each function and lines of code are doing. While doing this you will discover more often then not that when you though that you grasped the subject you haven’t, because if you struggle to write it down in your own words in comments, then it means you have not fully understand it yet. Another benefit of learning the hard way is that the memory retention of what you learned in the long term increases dramatically, when in contrast with when you just practice, or worst when you just read.
You can read more about learning the hard way here.
That works. However, my approach is different: Rewrite a pet project you have already done in a different language/technology stack. The pet project cannot be too trivial: A few thousand lines of code is fine. Since you know the problem very well, this exercise will get you up to speed in the new language pretty fast.
I agree with rewriting a project as you said, but only after the language is well understood, aka, after reading some books or watch video courses from more then one source.
Just quickly diving into the docs of the lang and then jump to code will put you on this situation I said above:
The Journey here is to understand the programming language in depth enough that you know how to properly leverage it and code efficiently with it, to then put in usage to rewrite a project as you advocate
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!
