You can’t skip loading on the initial render unless you are okay with that content a) popping in and b) not being present in the dead render (bad for SEO and bots and HN readers who claim to browse with JS disabled and so on). The problem with the pop-in is that it obviates one of the best “advantages” of LiveView, which is on-by-default SSR with no extra work.

Likewise you can’t skip loading on the live render because you need the assigns to actually run the LiveView.

The actual solution is that the assigns from the dead render need to carry on to the live render. One thing you could do is cache your queries so that the live render queries hit the cache. You could go further and cache the assigns specifically somehow.

But what should really be happening is that there should only ever be one LiveView process, with one set of assigns, which survives the dead render, and then the live render should be routed back to it when the socket is opened. A lot of things would have to be done to make that work and I’m not trying to make the claim that it would be easy, but from the API side I think it’s obviously the best design.

Async assigns are that API and are a fantastic solution to this exact problem. I really like async assigns, it’s very clear that a lot of care was put into handling the annoying edge cases properly. Honestly they might be the best-designed API in LiveView. Probably because they seem to have come directly from Chris dogfooding LiveView at Flyio.

But they don’t solve the double render, you would get pop-in.

If you’re looking to auth every route, you can put the auth plug before the Hologram handler in the endpoint.ex and, as you say, use the session for passing data around. This works well:

  # the plug 
  def call(conn, _opts) do
    case conn.req_headers |> Map.new() |> JWT.verify_header() do
      {:ok, jwt_data} ->
        Plug.Conn.fetch_session(conn)
        |> Plug.Conn.put_session(:email, jwt_data["email"])
      _ ->
        conn
        |> send_resp(403, "not authenticated")
        |> halt()
    end
  end

with this init in the layout:

  def init(_params, component, server) do
    email = get_session(server, :email)
    put_context(component, :email, email)
  end

(Admittedly, Google’s IAP is doing a lot of heavy lifting here and all I have to do is verify the JWT.)

I’m in the position of wanting one page, a health check for K8S, to not require auth. It would be easy enough to carve out a path-based exception but “security” and “exception” don’t always go well together.

Very nice. That works.
But like you said, with pipelines, it would be so much better.
Exceptions would keep on growing and would quickly become difficult to manage.
I don’t know what @bartblast has thought regarding authentication and authorisation.
Getting to know his take would be very helpful.

Thank you so much. This really clears things up.

The setup/3 function would receive the regular component and server structs, plus lower-level connection information like headers, and could modify both the server and component structs. This would give you the pipeline-like functionality you’re looking for.

This would be great.

Great job with Hologram. More power to you.

One unfortunate problem with LiveView being built on Phoenix (and therefore Plug) is that they ended up with two separate pipelines (one for the initial request, and then another for the socket). This complicates the developer experience and creates a performance problem (“double render”).

It would be nice if Hologram could avoid making this mistake, though it won’t be easy as there really are two requests under the hood and the framework needs to make it seem like there’s only one. Also it means you can’t rely on Plug the way Phoenix does because you need to abstract it away into the unified pipeline. So it’s a lot of extra work (which is of course why Phoenix ended up this way).