View Transition API in LiveView

Hey, I’m the one that has put that piece of code I tried several things till landing on that, but didn’t get any feedback from anyone doing something similar. Anyway you say it wraps too much code?

It literally just returns the promise that resolves into a function, do you mean the Topbar hide?

I also tried using a setTimeout, but I noticed sometimes it did get stuck loading the page. So I removed it.

Yes, as in the amount of code that runs between phx:page-loading-start and phx:page-loading-stop is too much. The callback in startViewTransition should only be wrapped around the code that updates the DOM. With your code it fetches the page, calculates the diff, applies the diff and maybe more, not sure.

This leads to unresponsive navigation for me and adds significant delay.

My version is “worse” in that it wraps an unknown amount of code that might or might not wrap the actual dom update. But for me it is still “better”, since it never slows down navigation, it just doesn’t always actually trigger the transition. If I increase the timeout to 100ms I can already feel the slowdown, so I kept it very low.

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

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.

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

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.

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.

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?

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