One thing I find is that I typically “start” with a LiveView even for static pages (in cases where I know I’m likely to add interactivity). I think it would be really awesome if we could do something like this:
def mount(...) do
socket
|> assign(...)
|> cancel_second_render()
end
This would essentially say “this is a static page. Don’t connect to the web socket, just render the HTML and be done”.
This means that you can have the benefit of a static html page very easily, without redesigning everything as a “dead view”. This is especially useful when you have that feeling “I know some day later I’ll probably want this to be a liveview”.
I‘ve thought about this as well in the past, but with live navigation I’m wondering if not starting the websocket is actually useful. I agree that being able to skip the second render would be nice though, given it‘s mostly needed for change tracking and asserting confidence over the match between server side state and local state.
Curious how live navigation works in between the first and second render. Or just while the ws is not connected. Do they in some way fall back to “regular” links?
Ya I think the easy way to roll this is put a data element on the body tag or something that uses a “@nolive” assign you set on the static render. Then in the JS code you check for that to be true and if it is, just don’t run the LiveView JS code.
They fall back to normal links doing navigation through the browser and plain http. But if you can you don‘t want this to happen, but rather opt for what live navigation does, which only happens via the websocket connection, skipping the http level additional render. Switching constantly between live and non-live pages kindoff denies making use of that optimization.
Yeah, thats an interesting idea Next time I have a case for it I may try that out, because that could at least provide the concept. I think having it in core sends a signal that it is okay to actually do that kind of thing (i.e you won’t break anything by not running the second render), but it makes sense to try the manual approach first.
Along these lines I would love it if event handlers could somehow be routeable. This would allow for truly progressive web apps (if you need it). I know there would be issues with this—for example and code that uses send won’t work anymore and it will probably become a come repeated question on this forum—but it could allow using most features for static HTML + POSTs.
Something like:
# router
live "/foos", FooLive do
post "/", event: "save"
end
# heex
~H"""
<.form for={@form} phx-submit="save" action={~p"/foos"} method="post">
"""
Very much spitballing here though have been thinking about it a little bit.
My point is that if the module doesn’t have a mount function it simply wouldn’t attempt to run code a second time anyway. There would be nothing to cancel @zachdaniel
"This means that you can have the benefit of a static html page very easily, without redesigning everything as a “dead view”. This is especially useful when you have that feeling “I know some day later I’ll probably want this to be a liveview”.
If this was implemented and make LV easily handle static pages then LV could be used as the default choice or would there stil be benefits to not use LV for something like a marketing/landing page?
If that’s the case then I’m surprised this suggestion & thread has not gotten more attention as it could have quite significant impact on both how LV itself is used and its role within phoenix?
I quite often see statments such as “LV is not good for this or that”, especially for static marketing or landing pages and this, if implemented, seems to then invalidate such arguments if I understand the situation correctly.
Next time I have a case for it I may try that out, because that could at least provide the concept. I think having it in core sends a signal that it is okay to actually do that kind of thing (i.e you won’t break anything by not running the second render), but it makes sense to try the manual approach first.
