LiveView: Feature to "cancel" second render

zachdaniel

Creator of Ash

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”.

42 comments

/phoenix #liveview

13 2091 42

2025-03-06 16:23:14 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

LostKobrakai

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.

Post #1

zachdaniel

Creator of Ash

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?

Post #2

mayel

If you simply don’t include the LiveView JS in the HTML of a page it won’t connect to websocket and won’t re-render.

Post #3

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #4

LostKobrakai

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.

Post #5

KP123

I wish we had separate load/3 and mount/3 functions. That plus being able to return json from render/1 would allow me to never use controllers again.

Post #6

zachdaniel

Creator of Ash

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.

Post #7

sodapopcan

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.

Post #8