I keep wondering if using only LiveView and no controllers is an idea worth pursuing. I tried this once and I would say the code got messy fast due to using generators. but perhaps if i write everything manually it’ll be okay?
Benefits of both approaches that i can think of:
MVC + LiveView benefits
static is easier to think about. seeing a static file in a project says quite a lot of what to expect inside.
easy session support (but rarely needed)
CRUD views are easier to read. or at least LiveView generators get a bit messy with modals and conditionals.
LiveView only benefits
single way of doing things. (main benefit, but what’s the reality, is code simpler?)
potentially faster navigation, but minor if any and in some situations probably slower.
once poject requirements change you don’t need to rewrite a static view to liveview.
no page_view.ex files that are mostly empty anyway.
I can understand that for a general website it makes sense to do landing page and login statically and app is probably dynamic so use LiveView. But is anyone experienced with doing everything in LiveView? what are the pitfalls?
Trouble is you’re still going to need controllers to do everything you need to do in liveview (session manipulation and the like). So the reasoning you outlined above is lost as you still need to support some controllers.
On a greenfield project I would always go LiveView everywhere when it comes to rendering some content, in my mind there is no real reason not to – I find mounting a liveview to be just as productive as creating a controller and an action with no drawbacks. Plus if the time comes to make the layout components live or migrate the deadview to a liveview for some functionality, this is already a non-issue.
I believe that with recent developments structuring a Phoenix application in terms of view concerns (rather than /controllers /views /templates doing /pages/page1 /pages/page2 or something to that extent do whatever you want) and keeping the controller/liveview/view/templates all colocated has become more of a valid option. Though I have been developing my greenfield projects like this for a while it now feels like customization of the web layer is being further incentivised in Phoenix 1.7.
Call me old fashioned but I still prefer dead views sometimes. They’re simpler and being able to reuse components, they’re seamlessly integrated with live views.
yeah, of course. should have mentioned the question is in regards to rendering content.
no drawbacks? interesting. what about performance for the client? not even sure. it’s hard to argue against this though, perhaps i will give this another go.
You must mean that alternative webservers are supported?
I’d erally be interested in PHP style /page/subpage/liveview.ex file structure. i know i could figure that out with Plug, but not Phoenix.
can you give an example of how they’re simpler? because the only argument i know of is sessions and that is generally only used for logging in. besides that - is there anything else that is simpler?
There is less thing happening, it is simple request response thing, there is no state, no bidirectional communication, no interactivity. There is less stuff = simpler.
i can understand the mental overhead of having to read through a LiveView just to find out there’s nothing dynamic in it, but then again if the liveview only has mount() then it’s pretty clear.
so if you don’t use state or interactivity, then should really be the same, no?
i suspect this may be more philosophical than technical.
