To someone who doesn’t understand these concepts, I think it’s far more likely that they would assume that “dead views” are the way to do this, and would not intuit this approach. Perhaps a guide? “Rendering Liveviews without connecting the socket” or something similar?
zachdaniel
Creator of Ash
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I am inclined to agree. On the one hand this isn’t hard to wire in from a “line of code” standpoint. And at the same time it does require touching code that, since it’s generated, people almost never look at, and aren’t always comfortable touching. This feels like a simple |> no_live helper in Phoenix that is then easy to document and see.
3
KP123
This is exactly why I suggested introducing two entirely new top level functions. Mount currently gets called twice once for dead render and once for live. Have a load function for dead render and live function for the connection load. Don’t want to connect as live view and stay dead? Don’t provide a live function. Perhaps behind the scenes that gets compiled down to the current mount with a check for if the socket is connected or not.
2
steffend
Phoenix Core Team
https://github.com/phoenixframework/phoenix_live_view/pull/3704
This PR introduces a new mount option called auto_connect. By default, it is true, which means that the LiveView JS will automatically connect to the server on dead render. If false, the connection will be skipped. The important difference compared to a no_live(socket) approach is that it does not suggest in any way that we should not connect when navigating from another LiveView when already connected.
8
rhcarvalho
Could it be that the problem is Controller+Template is less convenient than a single file LiveView?
And, in particular, that it could be easier to go from a static/dead page to a LiveView by changing only a few things like route definition and perhaps a top level use invocation in the controller to turn it into a LiveView? In addition to being able to colocate controller and template like in a LiveView.
I feel I can understand the wish to “default to LiveView for everything”, as I’m doing the same and writing a controller feels awkward.
But I also feel adding more modes to the LiveView lifecycle is going to make reasoning and creating a mental model of it even harder.
The original idea was to turn off the connected render. That affects existing patterns like deferring actions to the connected render, async assigns, pubsub subscriptions, etc.
Steffen proposed auto_connect: false with different semantics. IIUC that feature would create situations like a supposedly static page behaves differently if you load it via regular HTTP request or if you live navigate into it. Presumably, regular request would leave you in a disconnected state but live navigation would stay connected, changing the behavior of <.link>, for example.
So in one such LiveView’s that opted into auto_connect: false, mount would be called in either a connected or disconnected state. I think that requires a developer to understand all the nuances of the original lifecycle, plus this new mode, which is a net negative for me.
I think I’d rather revisit Controllers and see if working with them can be made more like the LiveView authoring experience.
0
steffend
Phoenix Core Team
Yes, but if the page actually uses any live features, you shouldn’t use auto_connect: false.
This came across my mind as well. Maybe what people actually want is a
defmodule MyAppWeb.DeadView do
use Phoenix.DeadView
def mount(params, session, conn) do
conn
|> assign(...)
|> then(&{:ok, &1})
end
def render(assigns) do
~H"""
...
"""
end
end
although mount might not be the correct terminology here. Then, to switch to a LiveView you “just” switch out the conn for a socket and replace use Phoenix.DeadView with use Phoenix.LiveView.
One drawback compared to auto_connect is that if you navigate to this page from a LiveView, the existing connection cannot be used and a regular request is performed instead.
1
rhcarvalho
I agree.
There’s an argument in recent messages that we’re adding this explicit feature for people who don’t understand every aspect of LiveView. That it would be hard for them to figure out they can simply change app.js to connect conditionally.
If I mentalize that persona, I suspect they might have a hard time deciding what they can or cannot do in a LiveView when they use auto_connect: false.
You captured what I meant well. On the router side, we would not say live SomeModule, but instead get/post/... so that we can handle only certain HTTP verbs, or a more generic catch all.
Maybe instead of mount/3 the callback would be HTTP-verb related?
0
zachdaniel
Creator of Ash
I think the important bit is the breadcrumb. People own’t understand everything, but if they search in the docs for the word “static page” and get linked to this option, the docs for this option can explain when it can and when it can’t be used etc.
0
zachdaniel
Creator of Ash
But I do agree, I think that it the docs for this might deserve its own section with an explanation of the kinds of things you can’t do w/ it.
0
rhcarvalho
I went to look at some code I wrote some months ago that fell into this category. To my own surprise, turns out I defined two modules in a single file to be able to colocate controller and template!
I understand controllers are a bit more complicated than LiveViews in this regard because they expose more flexibility, both in targeting different HTTP verbs and rendering different types of content from the same endpoint (HTML/JSON/etc).
Here’s a gist of the code I wrote, lib/myapp_web/controllers/temp_controller.ex:
defmodule MyAppWeb.TempController do
use MyAppWeb, :controller
def show(conn, %{"id" => id} = _params) do
# ...
render(conn, :show, id: id)
end
end
defmodule MyAppWeb.TempHTML do
use MyAppWeb, :html
attr :id, :integer, required: true
def show(assigns) do
~H"""
{{ @id }}
"""
end
end
router.ex:
# ...
get "/temp", TempController, :show
In my understanding I wouldn’t want to change anything in the router side. I could have a single controller and choose which function to call based on HTTP verb:
get "/temp", TempController, :show
post "/temp", TempController, :save
On the controller, there’s a difference compared to mount/3 in that there are 2 arguments, conn and params – no session. I think that’s okay.
When I call render, IIRC the expectation is that there’s a module with a name similar to the controller TempController → TempHTML, then I get to choose the template name which would typically be a file in disk. This part could be simplified, if I could write the template in the same module as the controller just like in LiveView.
Perhaps that could be done without changing Phoenix or LiveView, and instead updating the phx.new generator to make use MyAppWeb, :controller do some magic that “transforms a function returning HEEx in the controller module into a valid template”?
@zachdaniel does this resonate with your own needs?
I’ve also found a case where I deliberately made a static help page into a LiveView so that I can live navigate into and from it. If I would turn off the LiveSocket in this page, I would lose live navigation out of the page.
It also has the advantage that when I update the docs users immediately get to see the updated page without having to refresh.
0