Yes I know, that’s where I got it from. But with checking this you could differentiate your mount/3 between the first unconnected render and the next.
Hermanverschooten
1
zachdaniel
Creator of Ash
Hermanverschooten
zachdaniel
Creator of Ash
KP123
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
0
Kallee
"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?
0
zachdaniel
Creator of Ash
Kallee
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.
4
steffend
Phoenix Core Team
This is what I’d so as well. A dead render of a LiveView really is just a rendered HTML page. Nothing forces you to actually connect.
diff --git a/assets/js/app.js b/assets/js/app.js
index cfa128d..5b85399 100644
--- a/assets/js/app.js
+++ b/assets/js/app.js
@@ -33,8 +33,10 @@ topbar.config({barColors: {0: "#29d"}, shadowColor: "rgba(0, 0, 0, .3)"})
window.addEventListener("phx:page-loading-start", _info => topbar.show(300))
window.addEventListener("phx:page-loading-stop", _info => topbar.hide())
-// connect if there are any LiveViews on the page
-liveSocket.connect()
+// connect if there are any LiveViews on the page and no meta[name='no-live']
+if (!document.querySelector("meta[name='no-live']")) {
+ liveSocket.connect()
+}
// expose liveSocket on window for web console debug logs and latency simulation:
// >> liveSocket.enableDebug()
diff --git a/lib/demo_app_web/components/layouts/root.html.heex b/lib/demo_app_web/components/layouts/root.html.heex
index 436ea06..5990b0b 100644
--- a/lib/demo_app_web/components/layouts/root.html.heex
+++ b/lib/demo_app_web/components/layouts/root.html.heex
@@ -4,6 +4,7 @@
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="csrf-token" content={get_csrf_token()} />
+ <meta :if={assigns[:no_live]} name="no-live" content="true" />
<.live_title default="DemoApp" suffix=" · Phoenix Framework">
{assigns[:page_title]}
</.live_title>
And then just assign(socket, :no_live, true) and you’re good to go. I don’t think this needs a more “official” way to do.
4
zachdaniel
Creator of Ash
Honestly I think that it may be a tall order for people who don’t understand how LV works at a deeper level to understand the idea that not connecting is something safe or reasonable to do . The benefit of having a built in “if you don’t want to connect do this” pattern, like no_live(socket) or no_connect(socket) is that that gives you a place to explain these concepts to people, explain why you might want to do it, explain the tradeoffs, and make them feel comfortable that they aren’t somehow screwing some later thing up by using this approach.
Without that, it will always feel like something that might stop working someday, or something that might opt one out of some unknown benefit down the road.
3