Question on the usage of conn vs socket in a navigation

Very first Phoenix Liveview project. Probably my understanding of the life cycle is “weak” at this stage so I hope theses questions make sense.

All my pages are liveviews. The only time is need to declare a mount function is for a live module when I need some internal state, with handlers.

I can put a nav link inside “templates/layout/root.html.heex”, and use @conn in the links:
<li><%= live_redirect "demo", to: Routes.live_path(@conn, DemoWeb.HomeLive) %></li>.

I can also put a nav link in the “templates/layout/live.html.heex” but have to use @socket in the links.
<li><%= live_redirect "home", to: Routes.live_path(@socket, DemoWeb.HomeLive) %></li>

Where does @conn come from for the “layout/root” case? And where does the @socket comes from as well for the “layout/live” case?

Answering to myself if any interest:

An HTTP request is processed with Plug that creates a Plug.Conn alias conn struct. Thus you have the conn struct when navigating in a non-liveview page.
With liveviews, it is a websocket and you get a socket struct.

2 Likes

Can you explain what is the difference between socket and conn?

socket => websockets (stateful and ongoing two-way connections)
conn => HTTP request/response (stateless and one-off one-way connections)

4 Likes

Plug.Conn represents an ordinary HTTP request. But this request can start a Liveview. And inside a live view, there is Phoenix.LiveView.Socket which represents a websocket

1 Like

Yup, websocket connection are just upgraded HTTP connections!

Protocol upgrade mechanism

The HTTP/1.1 protocol provides a special mechanism that can be used to upgrade an already established connection to a different protocol, using the Upgrade header field.

This mechanism is optional… and in practice, this mechanism is used mostly to bootstrap a WebSockets connection.

source: Protocol upgrade mechanism - HTTP | MDN

And with LiveView, the handoff between the two is configured and can be customized as described here.

1 Like