View Transition API in LiveView

This is my experience as well.

I dont think its possible to get a double transition. There can only be one view transition at a time.

On navigating to a new live_session, the css transition will kick in. And if you also use start_view_transition in the mount callback I think it just does nothing since the other transition is still going.

I saw the video of your demo! Do you need to take special care to avoid a double transition between live_session boundaries? Because that would be a full page load, IIUC triggering the MPA page transition, and then… where in the lifetime of the LiveView do you call the new/proposed API? I’ll go have a look at the demo code

For dead/static render view transitions between pages can easily be done just with css. You only need:

@view-transition {
  navigation: auto;
}

See Cross-document view transitions for multi-page applications  |  View Transitions  |  Chrome for Developers

But when using live navigation or for same document transitions we need support in live_view, like I’m proposing in the other thread:

I didn’t use view transitions in production yet.

Reading on MDN and thinking about how it applies to LiveView, I see we have both MPA-type transitions for disconnected mount and regular links / crossing live_session boundaries, and SPA-style transitions for live navigation, live patch, and other DOM updates.

What’s been your experience making transitions working consistently regardless of socket connected/disconnected state?

I have been playing around with a fork of liveview to implement a proper API for this.

Here’s a small video of a demo app with view transitions implemented with my fork: https://imgur.com/a/tGz06Eb
Still very rough, but it demonstrates that it works.

The API I implemented is: JS.start_view_transition and start_view_transition(socket).
types can be passed as an option.

I also needed to add a temp_name option, which allows implementing this common technique of giving an element a transition name just for the start of the view transition, like they do in this article: Same-document view transitions for single-page applications  |  View Transitions  |  Chrome for Developers.
Doing that looks like this:
JS.start_view_transition(temp_name: "img-full", to: "#element") |> JS.navigate("/card/#{@id}")

Once I’ve cleaned this up I’ll probably create a new post to propose this API and if deemed worthy enough I can open a PR.

Actually, I think a better API might be to operate at the socket level, similar to push_navigate.
Because the API I proposed above wouldn’t work for triggering a view transition when deleting something from a list.

So maybe something like: start_view_transition(socket, types \\ [])
And there could be a corresponding JS.start_view_transition(js, types \\ []) which would be used together with JS.toggle() and similar for client side only dom mutations.

Yeah, seems like only very few are interested in this. I think view transitions are a huge deal and will make the web platform much closer to native apps.

I found this blog post which has an interesting hack to do it “properly”.
I modified it slightly by adding type == "mount" such that it only transitions when navigating between pages:

  // deps/phoenix_live_view/priv/static/phoenix_live_view.esm.js
  applyDiff(type, rawDiff, callback) {
    this.log(type, () => ["", clone(rawDiff)]);
    const { diff, reply, events, title } = Rendered.extract(rawDiff);
    if (document.startViewTransition && type == "mount") {
      document.startViewTransition(() => callback({diff, reply, events}))
    } else {
      callback({diff, reply, events})
    }
    if (typeof title === "string" || type == "mount") {
      window.requestAnimationFrame(() => dom_default.putTitle(title));
    }
  }

Apart from the js asset patching hackery, this is pretty much perfect! No flakyness, no delays, perfectly smooth transitions!

Obviously this isn’t good enough to get into liveview.
A proper solution would have some way for users to opt in to the transition on changes.

Maybe the API could be something like:

# Calls startViewTransition on mount
<div phx-view-transition >...

# Results in: startViewTransition({ types: ["slide", "backwards"], update: ... })
<div phx-view-transition={["slide", "backwards"]} >...

This API would allow page transitions by using this in our layout component. But it would also allow same document view transitions by using it more granularly.
Only problem with this API would be that If multiple elements with this attribute are mounted in the same frame its not clear which one will “win”.

Yes, that was something I faced when using something similar to what you have. This code I posted isn’t yet pushed to prod, I’m still exploring the best way forward with MPA View Transitions and Phoenix, there isn’t much to lean into, we are the canary in the mine.

Don’t know that much about startViewTransition will explore a bit more and dig into it.