(re)learning Phoenix - skip LiveView? avoid scaffolds?

Q1: are there any good current resources or guides which focus on basic Phoenix with html views?

Q2: is LiveView worth the additional complexity if target users will have poor internet connectivity and if the app is just a basic web app with some forms and views?

Q3: should scaffolds be avoided?

It seems most educational content is focused on LiveView, and secondarily on APIs. I am having difficulty finding something like the old Programming Phoenix book from 5 years ago (or like the Rails Depot book).

My target user will be in places where connectivity is unreliable, so it is my understanding that LiveView may not be the best approach. And based on my one project experience of the past, standard Phoenix html views are very performant already… so “liveness” doesn’t seem to add value in line with the additional complexity.

1 Like

The official hexdocs page of Phoenix does not seem to focus on LiveView.

4 Likes

Nitpick: If anything, LiveView removes complexity! But if you are dealing with spotty connections then it’s probably best not to use it.

As @dimitarvp pointed out (and is a common answer 'round here), the official guides are always the way to go :slight_smile:

Scaffolds don’t need to be avoided if you are creating a relatively simple CRUD-based application. There’s a good chance you will start to feel the pain and wanting more control as your app get more complex at which point you’ll likely naturally start to migrate away from using them.

1 Like

Q2: for your use case LiveView is not worth it, in my opinion.

I wish there was more support for the approach of LiveView sprinkled on top of basic Phoenix views though. My understanding is that currently you have to choose between the two.

You can use live_render/3 to render a LiveView within a dead view.

1 Like

From the up-to-date official docs - “You can serve the LiveView directly from your router (recommended)”.

I know that we can use live_render/3, but since it is not recommended way imho it was given less attention and there are might be edge cases which make using mixed approach not ideal. One that I know of is about maintaining scroll position for LiveView → RegularView → back to LiveView transitions.

Ya, the losing the scroll position is annoying. I was hoping that was going to get fixed soon. Maybe I should try, ha. I know there have been a few attempts.

I guess when you said “sprinkled” I thought you meant like (live) widgets. It’s totally fine to use live_render for that use-case. As far as I’m concerned, the docs are just recommending you don’t create a controller with a template for the sole purpose of rendering a LiveView.

Agreed that if you have both low-js needs and low-connectivity LV is not really a good option right now.

If you have really focused need for “rich” components in specific places then using live_render might make sense (maybe with some connectivity aware wrapper so it can gracefully degrade), but if you have other JS needs it might be better to use a pure (FE only) JS lib.

I meant that, yes. What I discovered though is that sprinkling widgets “turns” regular view to LiveView and we are back to scroll position issues when transitioning to or from “real” regular views.

Oh it does? That’s too bad. I suppose that makes sense since the whole connection is being upgraded to a websocket.

1 Like