Add support for View Transition API

[AkifumiSato]

Describe the feature you'd like to request

I would like to perform animation during transitions.
e.g. Transition as if opening a modal in a native app.

Describe the solution you'd like

Support the View Transitions API.
https://developer.chrome.com/docs/web-platform/view-transitions/

If we can pass the navfation in Next.js to document.startViewTransition, we should be able to achieve this.

function spaNavigate(data) {
  // Fallback for browsers that don't support this API:
  if (!document.startViewTransition) {
    updateTheDOMSomehow(data);
    return;
  }

  // With a transition:
  document.startViewTransition(() => updateTheDOMSomehow(data));
}

Describe alternatives you've considered

It would be difficult to support on its own.

[Fredkiss3]

Since viewTransition api is mostly for Multi pages Application (MPA), while nextjs is SPA-first oriented. You could implement such a thing by disabling all links or not using the Link component in your project for navigations.

Since this feature is also, not yet implemented by many vendors it will take a long time before any framework (next included) start looking to integrate it.

[AkifumiSato]

The View Transitions API is not intended for MPAs, but for SPAs.
https://developer.chrome.com/docs/web-platform/view-transitions/#why-do-we-need-this-feature

Additionally, although the current implementation targets single page apps (SPAs), this feature will be expanded to allow for transitions between full page loads, which is currently impossible.

The question is whether Next.js and React can and will support this.

[matamatanot]

Chrome 111 was released!
https://caniuse.com/mdn-api_viewtransition

[pavelglac]

Would be nice to integrate it into the router. I assume it has to be achieved by flushSync where the new startViewTransition API can be called.

[jakearchibald]

Some insight into how view transitions work:

document.startViewTransition(async function viewTransitionCallback() {
  // Change the DOM here
});

When you call startViewTransition, that's the signal for the browser to capture the current state, which will be the 'old' state in the transition. That capture happens asynchronously.

Once the capture is complete, the viewTransitionCallback is called.

The DOM must be updated to the 'new' state before the promise returned by viewTransitionCallback fulfills.

Then, the browser captures the new state, and creates a transition between them.

Between the browser calling viewTransitionCallback and the returned promise settling, rendering is frozen to prevent the user seeing a flash of the new content. Freezing should be kept to a minimum (like, don't do network stuff here).

The ideal pattern for a 'navigation' is this:

await fetchEverythingNeededForTheNavigation();

document.startViewTransition(() => {
  switchToTheNewView();
});

Svelte are looking to add a hook for this:

onNavigate(async (navigation) => {
  return new Promise((oldStateCaptureResolve) => {
    document.startViewTransition(() => {
      oldStateCaptureResolve();
      await navigation.complete;
    });
  });
});

Where:

• onNavigate is called just before navigation is applied (after related fetching)
• Returning a promise from the onNavigate callback delays the DOM change
• navigation.complete resolves once the DOM change is complete

This lets view transitions fully integrate with the Svelte router.

[aggroot]

Nuxt is also going to support it https://nuxt.com/docs/getting-started/transitions#view-transitions-api-experimental

[yanai101]

also astro in v3

[khuezy]

There's no support for the new next/navigation router events. The official recommendation is to use useEffect and watch for usePathname, but that's after the routing has transitioned. So it looks like there's no way to call document.startViewTransition before the route changes.

[nmn]

I was playing around this on my own, and something like this will usually work for View Transitions:

function useTransitionWithCompletion() {
  const [isPending, startTransition] = useTransition();
  
  const pendingPromise = useRef();
  
  useLayoutEffect(() => {
    if (!isPending && pendingPromise.current) {
      pendingPromise.current.resolve();
      pendingPromise.current = undefined;
    }
  }, [isPending]);
  
  useLayoutEffect(() => () => {
    if(pendingPromise.current) {
      pendingPromise.current.reject();
      pendingPromise.current = undefined;
    }
  }, [])
  
  const startTransitionWithCompletion = (transition) => {
    const promise = new Promise((resolve, reject) => {
      pendingPromise.current = {resolve, reject};      
    });
    
    startTransition(transition);
    
    return promise;
  };
  
  return [isPending, startTransitionWithCompletion]
}

Now you can use this hook instead of useTransition and the startTransition function will return a promise that can be fed into document.startTransition.

The main problem is of course that this fires for React transitions that have both completed or canceled. (Which may sometimes be OK)

[AkifumiSato]

I tried this and it worked. I just changed reject to resolve because consider unmounting during transitions.

  useLayoutEffect(
    () => () => {
      if (pendingPromise.current) {
        pendingPromise.current.resolve();
        pendingPromise.current = undefined;
      }
    },
    [],
  );

Component implementation of the AnimationLink.

export function AnimationLink({
  children,
  href,
  ...props
}: {
  children: React.ReactNode;
  href: string;
} & React.ComponentProps<typeof Link>) {
  const router = useRouter();
  const [_isPending, startTransitionWithCompletion] =
    useTransitionWithCompletion();
  const onClick = useCallback<React.MouseEventHandler<HTMLAnchorElement>>(
    (e) => {
      e.preventDefault();
      documentTransition(() =>
        startTransitionWithCompletion(() => {
          router.push(href);
        }),
      );
    },
    [router, href, startTransitionWithCompletion],
  );

  return (
    <Link {...props} href={href} onClick={onClick}>
      {children}
    </Link>
  );
}

However, returning a browser back Promise is difficult.
@nmn Do you have any ideas?

[nmn]

No ideas about how to tackle that. To handle the back button, changes to the Next router would need to be made. Which is why, I guess, this discussion exists!

[khuezy]

I'm able to get this working in a decent state w/ the current version of Nextjs. The only issue I have left is the browser back/forward button doesn't trigger the animation - even though I do see ::view-transition appended to the DOM.

The way I start the capture before the transition is by wrapping the next/link component (please let me know if there's a way or a new router hook event):

import NextLink from 'next/link'

export function Link(props: AnchorHTMLAttributes<HTMLAnchorElement>) {
   return <NextLink {...props} onClick={async () => {
      await document.startViewTransition(()=> new Promise(res => setTimeout(res, 1)).finished
      document.documentElement.classList.remove('back-transition')
   }} />
}

I have a hook that watches post route changes:

'use client'

import { usePathname } from 'next/navigation'
import { useEffect, useRef } from 'react'

export const useNavigationEvent = (onChange: (pathname: string, isBack: boolean) => void) => {
  const pathname = usePathname()

  const last = useRef(pathname)

  useEffect(() => {
    const isBack =  last.current.startsWith(pathname)

    if (last.current !== pathname) {
      onChange(pathname, isBack)
    }
    last.current = pathname
  }, [pathname, onChange])
}

I use this to add "back-transition" if the route went back: document.documentElement.classList.add('back-transition')

[khuezy]

Edit: I tried using the /pages with next/router and hooked onto router.events routeChangeStart and routeChangeComplete and it works like a charm, including the browser back/forward button...
@leerob When can we expect the route change hooks in appDir sir?

[khuezy]

I'm able to get the back/forward button to work, but it's sometimes flaky.

// A client component near the root
import { useTransition } from 'react';

export default function SomeComponent({children}) {
  const [, startTransition] = useTransition()
  useEffect(() => {
     window.onpopstate = function() {
        startTransition(() => document.startViewTransition())
     }
  }, [])
  
  return children
}

This is a pretty bad hack but it works most of the time.

[IgorSzukalo]

You can move the promise resolve to useLayoutEffect clean-up function for more consistent updates.

export function Link(props: AnchorHTMLAttributes<HTMLAnchorElement>) {
  const pathname = usePathname();

  const promiseCallbacks = useRef<Record<
    'resolve' | 'reject',
    (value: unknown) => void
  > | null>(null);

  useLayoutEffect(() => {
    return () => {
      if (promiseCallbacks.current) {
        promiseCallbacks.current.resolve();
      }
    };
  }, [pathname]);

  return (
    <NextLink
      {...props}
      onClick={async () => {
        await document.startViewTransition(
          () =>
            new Promise((resolve, reject) => {
              promiseCallbacks.current = {
                resolve,
                reject,
              };
            })
        );
      }}
    />
  );
}

[TommySorensen]

Maybe we can use the new template file for something like this?
https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts#templates

[khuezy]

How would we detect when the route start and ends? Can we do something like:

useEffect(() => {
   // component is rendered, is this routeChangeComplete?
   return () => {
      // route will get unmounted, is this routeChangeStart?
   }
})

This unfortunately doesn't work.

[petdomaa100]

This is what I came up with, seems to be working really well.

import { useTransition, useEffect } from 'react';
import { useRouter as useNextRouter } from 'next/navigation';

function useRouter(): ReturnType<typeof useNextRouter> {
  const [ , startTransition ] = useTransition();
  const router = useNextRouter();

  function safeViewTransition(fn: (...args: any) => any) {
    if (document.startViewTransition !== undefined) {
      document.startViewTransition(fn);
    } else {
      startTransition(fn);
    }
  }

  return {
    ...router,
    back: () => {
      safeViewTransition(() => router.back());
    },
    forward: () => {
      safeViewTransition(() => router.forward());
    },
    push: (...args: Parameters<typeof router.push>) => {
      safeViewTransition(() => router.push(...args));
    },
    replace: (...args: Parameters<typeof router.replace>) => {
      safeViewTransition(() => router.replace(...args));
    }
  };
}

Adding similar logic to window.onpopstate also works like a charm.

[khuezy]

Are your transitions 100% consistent? I've had instances where the animations don't play at all.

[jakearchibald]

This won't be consistent, because it doesn't handle async route changes. See #46300 (comment) for the kind of API needed to make this work.

[petdomaa100]

It seems to be working quite consistently if I prefetch the pages before navigation. (router.prefetch('/page');)

[AaronLayton]

I attempted to use this but got no transitions at all when navigating pages in dev. However if I try to navigate to the exact same page then the transitions would play.

[TommySorensen]

It seems like they added some minimal description of how to do router events here. I guess we could use this to start the page transition?
https://nextjs.org/docs/app/api-reference/functions/use-router#router-events

[khuezy]

That doesn't work unfortunately, as that is detected after the route has transitioned.

[AaronLayton]

I feel like I am so close now to having a working solution with the app router, just some edge cases to iron out. I have mixed in different approaches from all comments thus far and attempted to make things clean and tidy but alas it got messy.

I will pick up again tomorrow and see what I can come up with

chrome_Ea7EAgLSVd.mp4

[khuezy]

Looks good! Please keep us updated.

[AaronLayton]

OK I didn't get chance to go further into it yet and instead going to share the code so other people have had a stab at it, and let me caveat this with I was drinking and coding 😅 so this is by no means nice code.

notes

• Back / Forward is still buggy. I was messing around in this area and trying different things, digging into the NextJS source code also.
• Page transitions work really well, I have not had that mess up
• Utilises the transitionHelper that @jakearchibald created as I was planning on implementing the class names for Back / Forward transitions
• When using push(url) it would probably be good to pass in optional classes there, or at least say if this was a forward or backwards action so you can append the correct classes to the body.
• The way we are doing the popstate transitions are incorrect. If you go slowly then the transitions work, if you try and navigate back 2 or 3 times fast then it just skips the transition altogether

types/missing-types.d.ts

interface ViewTransition {
  finished: Promise<void>;
  ready: Promise<void>;
  updateCallbackDone: Promise<void>;
}

interface Document {
  startViewTransition(setupPromise: () => Promise<void> | void): ViewTransition;
}

lib/transitionHelper.ts

interface TransitionHelperArg {
  skipTransition?: boolean;
  classNames?: string[];
  updateDOM: () => Promise<void> | void;
}

export function transitionHelper({
  skipTransition = false,
  classNames = [],
  updateDOM,
}: TransitionHelperArg) {
  if (skipTransition || !document.startViewTransition) {
    const updateCallbackDone = Promise.resolve(updateDOM()).then(() => {});
    const ready = Promise.reject(Error("View transitions unsupported"));

    // Avoid spamming the console with this error unless the promise is used.
    ready.catch(() => {});

    return {
      ready,
      updateCallbackDone,
      finished: updateCallbackDone,
      skipTransition: () => {},
    };
  }

  document.documentElement.classList.add(...classNames);

  const transition = document.startViewTransition(updateDOM);

  transition.finished.finally(() =>
    document.documentElement.classList.remove(...classNames)
  );

  return transition;
}

hooks/useViewTransitionRouter.ts

import { useTransition, useEffect, useLayoutEffect, useRef } from "react";
import { useRouter as useNextRouter, usePathname } from "next/navigation";
import { transitionHelper } from "@/lib/transition-helper";

function useViewTransitionRouter(): ReturnType<typeof useNextRouter> {
  const router = useNextRouter();
  const pathname = usePathname();
  
  const promiseCallbacks = useRef<Record<
    "resolve" | "reject",
    (value: unknown) => void
  > | null>(null);

  useLayoutEffect(() => {
    return () => {
      if (promiseCallbacks.current) {
        promiseCallbacks.current.resolve(undefined);
        promiseCallbacks.current = null;
      }
    };
  }, [pathname]);

  return {
    ...router,
    back: () => {
      transitionHelper({
        updateDOM: () => router.back(),
      });
    },
    forward: () => {
      transitionHelper({
        updateDOM: () => router.forward(),
      });
    },
    push: (...args: Parameters<typeof router.push>) => {
      transitionHelper({
        updateDOM: () => {
          const url = args[0] as string;
          if (url === pathname) {
            router.push(...args);
          } else {
            return new Promise((resolve, reject) => {
              // @ts-ignore
              promiseCallbacks.current = { resolve, reject };
              router.push(...args);
            });
          }
        },
      });
    },
    replace: (...args: Parameters<typeof router.replace>) => {
      transitionHelper({
        updateDOM: () => router.replace(...args),
      });
    },
  };
}

export default useViewTransitionRouter;

From this point you can import useViewTransitionRouter() like this and push new pages. This covers the normal page transitions.

components/new-link.tsx

import useViewTransitionRouter from "@/hooks/useViewTransitionRouter";
import NextLink, { LinkProps as NextLinkProps } from "next/link";

type AnchorProps = Omit<
  React.AnchorHTMLAttributes<HTMLAnchorElement>,
  keyof NextLinkProps
>;

interface LinkProps extends AnchorProps, NextLinkProps {
  children: React.ReactNode;
}

const Link: React.FC<LinkProps> = ({ ...props }) => {
  const router = useViewTransitionRouter();

  const handleLinkClick = async (e: React.MouseEvent<HTMLAnchorElement>) => {
    e.preventDefault();

    router.push(props.href.toString())
  };

  return <NextLink {...props} onClick={handleLinkClick} />;
};

export default Link;

To get the Back / Forward transitions working this is the tricky part, but was attempting to follow the same pattern

components/transition-provider.tsx
Wrap you app in this provider. I was going to explore creating a context.

Note: this is a mess as it was the part I was playing around with, leaving everything in there so you can hopefully see the thought pattern

"use client";

import { transitionHelper } from "@/lib/transition-helper";
import React, { TransitionFunction, use, useEffect, useLayoutEffect, useRef, useTransition } from "react";

const TransitionProvder = ({ children }: { children: React.ReactNode }) => {
  const [isLoading, startTransition] = useTransition();

  const promiseCallbacks = useRef<Record<
    "resolve" | "reject",
    (value: unknown) => void
  > | null>(null);

  useEffect(() => {
    window.onpopstate = function () {
         console.log("TRANSITIONER - POPSTATE");
        // transitionHelper({
        //     updateDOM: () => {
        //         return new Promise((resolve, reject) => {
        //             // @ts-ignore
        //             promiseCallbacks.current = { resolve, reject };
        //         });
        //     }
        // });
        document.startViewTransition(() => {
            // return new Promise((resolve, reject) => {
            //     // @ts-ignore
            //     promiseCallbacks.current = { resolve, reject };
            // });
        });
        startTransition(() => {});
    };
  }, []);

  useLayoutEffect(() => {
    console.log("LAYOUT EFFECT PROVIDER");

    return () => {
        console.log("TRANSITIONER - END");
        if (promiseCallbacks.current) {
            console.log("TRANSITIONER - RESOLVE");
            promiseCallbacks.current.resolve(undefined);
            promiseCallbacks.current = null;
        }
        };
  });
    

//   useEffect(() => {
//     console.log("TRANSITIONER - START");
    
//     if (isLoading && !promiseCallbacks.current) {
//         console.log("TRANSITIONER - SETUP");
//         promiseCallbacks.current = {
//             resolve: () => {},
//             reject: () => {},
//         };
//     }

//     return () => {
//         console.log("TRANSITIONER - END");
//         if (promiseCallbacks.current) {
//             console.log("TRANSITIONER - RESOLVE");
//           promiseCallbacks.current.resolve(undefined);
//           promiseCallbacks.current = null;
//         }
//       };
//   }, [isLoading]);

  return children;
};

export default TransitionProvder;

app/layout.tsx

/* ... */
return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <TransitionProvder>
            {children}
        </TransitionProvder>
      </body>
    </html>
  );
/* ... */

[AaronLayton]

Just attempting something a little more in depth

chrome_Zemi0T7D8W.mp4

Inspired by https://live-transitions.pages.dev/

[godfrednanaowusu]

This looks fantastic, have you been able to figure out the things left?

[noamr]

I wrote a custom hook for automatic view-transitions in NextJS that works without having to refactor the Link element:
https://github.com/noamr/use-view-transitions

It uses the fact that the NextJS router calls startTransition for navigations, and delays all of React's "lower priority" work until the startVT callback is called.
Part of it is a bit hacky though - a better solution IMO would be if Next had a config where startViewTransition is called instead of React.startTransition inside the app router.

[DavidMulder0]

@noamr That's surprising, on Chrome Canary on Windows (did an entire project in a different framework that uses the View Transitions API, so it definitely works on my PC (also https://http203-playlist.netlify.app/ works in the browser)). It behaves the way where after a click it freezes and then 'gives up' and shows the post transition state after two seconds.

[noamr]

this happens when you click what? There are lots of transitions there.

[markojak]

Can't wait for this to be available
Pretty slick demo on Astro

https://youtu.be/lsXqparnx24

[landsman]

@DavidMulder0 in my chrome on macOS there is like 1s delay before animation start, no activity indicator.

[DavidMulder0]

I was just rereading this discussion, and realized I never left a comment here. My previous comments shows why it's CRUCIAL to call the startTransition only after all network requests resolve, you should NEVER do a network request inside your transition, but network requests can based on the user's internet take a long while.

(nevermind, found my comment below, it just didn't get added to thread correctly, as I replied to an email notification -_-)

[noamr]

Some notes after playing with this a lot:

• Providing an HOC that adds view-transitions to a Link would sort-of work, but would be:
  • not great DX. You need to S&R a lot.
  • Hard to understand when the navigation is complete/settled and the new state can be captured.

This was possible before with router.events.

I think a possible good solution that can't be done in userland would be to make a configurable option that makes router-links start a view transition rather than a react startTransition (with the latter as a fallback when the feature is not available). With that in place, developers can customize the rest with CSS.

[leerob]

The code snippet shown there is for use in the App Router. Just wanted to mention that while a 1:1 solution of router.events does not exist, there are some parallels with newer routing hooks.

[TommySorensen]

@leerob Are there any plans in the Next.js roadmap to have some build-in events for View Transitions API?

[noamr]

New version supports AppRouter, but it's even more hacky because it needs to capture clicks.

[khuezy]

I tried adding a component in the Suspense fallback component to capture the event before a new route is transitioned, but I believe that only ever gets triggered on the first load. The subsequent loads do not get Suspense'd probably because the route is cached?

[TommySorensen]

@leerob Any news on this? I see other major frameworks added support for this API. Next.js should also support it, or at least have it in the pipeline.

[leerob]

Overall, the answer is yes, we want to support the View Transitions API. I am not sure when, or exactly how, but I love how it's pushing the web forward. If you'd like to see support for this, please upvote this discussion 😄

[nicolaslair]

"Pushing the web forward" - I feel like I will finally be able to redo the Flash websites I was doing in 2010 :)

[dayblox]

Can't wait for this to be supported by Next.js!

[burhan-sancakli]

I hope Nextjs14 supports this

[mruba]

yes please I would love to use this feature!

[Deer404]

support this

[adelpro]

Using NextJS 13 with app-router, This is my solution: i created a hook: useAnimatedRouter

// useAnimatedRouter.ts
"use client";
import { ExtendedDocument } from "@/types/extendedDocument";
import { useRouter } from "next/navigation";

export default function useAnimatedRouter() {
  const router = useRouter();
  const viewTransitionsStatus = () => {
    const extendedDocument = document as ExtendedDocument;
    let status = "Opss, Your browser doesn't support View Transitions API";
    if (extendedDocument?.startViewTransition) {
      status = "Yess, Your browser support View Transitions API";
    }
    return status;
  };
  const animatedRoute = (url: string) => {
    const extendedDocument = document as ExtendedDocument;
    if (!extendedDocument?.startViewTransition) {
      return router.push(url);
    } else {
      extendedDocument.startViewTransition(() => {
        router.prefetch(url);
        return router.push(url);
      });
    }
  };
  return { animatedRoute, viewTransitionsStatus };
}`
this hook have two functions

1. viewTransitionsStatus: that return a message showing is the browser support the View Transitions API.
2. animatedRoute: that encapsulate the router.push() end add support for the View Transitions API (if supported)
 To make typescript happy, we have extended the document type with the new experimental View Transitions API:
`export interface ExtendedDocument extends Document {
  startViewTransition?: any;
}
`
You can use the animatedRoute to replace the default router.push() behavior.
We can also extend the default Link component like this:
`"animatedLink.tsx"
import useAnimatedRouter from "@/hooks/useAnimatedRouter";
import Link from "next/link";
import React from "react";

type Props = {
  href: string;
  children: React.ReactNode;
};
export default function AnimatedLink({ href, children }: Props) {
  const { animatedRoute } = useAnimatedRouter();
  return (
    <Link
      href={href}
      onClick={() => {
        console.log("Animated link clicked!");
        animatedRoute(href);
      }}
      passHref
    >
      {children}
    </Link>
  );
}

Now you have to add View Transitions API CSS code in the Global.css file.
This Approach works very well, but we have two issues:

1. When you click the back button from the browser
2. With dynamic routes, for example localhost:3000/articles/[id]

Read more

[spacedev75]

any update on this ? nuxt.js, astro and svelte already got their implementations of view transition API..

[matamatanot]

Chrome for Developers introduces an example of View Transition API with Next.js.

https://developer.chrome.com/blog/view-transitions-case-studies/#technical-details-of-implementation-1

[phcorp]

Here is a solution that works for me: (use it at your own risk)

1. create a hook useViewTransition.tsx in your hooks directory

'use client';

import React, { MutableRefObject, useEffect, useRef } from 'react';

interface Document {
  startViewTransition?: any;
}

const getTargetNode = (targetNodeRef: MutableRefObject<any>): HTMLElement|null => targetNodeRef?.current?.el;

const arePathnamesEqual = (a: string, b: string): boolean => {
  const languageExtractionRegex = /^\/(\w{2})(\/.*)$/;
  const aMatches = a.match(languageExtractionRegex);
  const bMatches = b.match(languageExtractionRegex);
  const [, aLang, aPath] = aMatches ?? [null, null, a];
  const [, bLang, bPath] = bMatches ?? [null, null, b];

  return !!(((aLang === bLang) || (aLang && !bLang) || (!aLang && bLang)) && aPath === bPath);
};

/**
 * @see https://github.com/vercel/next.js/discussions/46300#discussioncomment-7247648
 */
export default function useViewTransition(
  targetNodeRef: MutableRefObject<any>,
): {
  isViewTransitioning: () => boolean,
} {
  const deferred = useRef<{ resolve: any, reject: any}|null>(null);
  const nextUrl = useRef<URL|null>(null);

  useEffect(() => {
    const targetNode = getTargetNode(targetNodeRef);
    if (!targetNode || !('MutationObserver' in window) || !('startViewTransition' in window.document)) {
      return;
    }

    const startViewTransition = (): void => {
      const deferredPromise = new Promise((resolve, reject) => {
        deferred.current = {resolve, reject};
      });
      document.startViewTransition(async () => {
        await deferredPromise;
      });
    };

    const endViewTransition = () => {
      deferred.current?.resolve();
      deferred.current = null;
    };

    const mutationObserver = new MutationObserver(endViewTransition);
    mutationObserver.observe(targetNode, {
      childList: true,
    });

    const linkClickListener = (event: MouseEvent) => {
      const { location } = document;
      const eventTargetNode = event.target as HTMLAnchorElement|null;
      const link = eventTargetNode?.tagName.toLowerCase() === 'a'
        ? eventTargetNode
        : eventTargetNode?.closest('a');
      if (!link) {
        return;
      }
      const currentUrl = new URL(link.href);
      if (currentUrl.origin !== location.origin || arePathnamesEqual(currentUrl.pathname, nextUrl.current?.pathname ?? '')) {
        return;
      }
      endViewTransition();
      requestAnimationFrame(() => {
        startViewTransition();
      });
    };
    targetNode.addEventListener('click', linkClickListener, {
      capture: false,
    });

    return () => {
      mutationObserver.disconnect();
      targetNode.removeEventListener('click', linkClickListener, {
        capture: false,
      });
    };
  }, [deferred, nextUrl, targetNodeRef]);

  return {
    isViewTransitioning: () => {
      return !!deferred.current;
    }
  };
}

2. update your app to use your newly created hook

'use client';

import useViewTransition from '@hooks/useViewTransition'; // this path may be different in your project
import { App } from 'konsta/react'; // also my project setup
import React, { useRef } from 'react';

export default function MyApp({
  children,
}: {
  children: React.ReactNode,
}): JSX.Element {
  const ref = useRef<HTMLElement|null>(null);
  useViewTransition(ref);

  return (
    <App ref={ref} safeAreas theme="ios">
      {children}
    </App>
  );
}

[graup]

I don't think this works with the back button, does it? There is no fetch when going back.

[phcorp]

yes unfortunately it is not possible to detect back event AFAIK the popstate event is fired after navigation

maybe there is a lead here: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming/type (EDIT not working)

[FrameMuse]

Have you tried using new Navigation API? It introduces new "onnavigate" callback, which is fired before navigation.
https://developer.chrome.com/docs/web-platform/navigation-api/

[phcorp]

I tried to adapt my code to use that but the onnavigate callback seems to be triggered a little too late

[burhan-sancakli]

Any update yet? I hope Nextjs14 has this at least experimentally

[AaronLayton]

I've been playing around with Partial Pre-Rendering and Streaming responses with Suspense boundaries and think there will be issues around this with ViewTransitions.

If we are streaming the response to the browser then that means the DOM / Load events are not fired until all the Suspense boundaries are resolved. In my testing at least, this means whilst we get a fast TTFB the actual full page loads are easily over 600ms for just a simple DB query to get a ViewCount for the current page (PlanetScale / Prisma).

If pages take this long, won't we fall into a timeout on the startViewTransition as I believe it has a pretty aggressive timeout (although can't find any mention of the timeout atm).

Does anyone here have experience with how other frameworks do this with dynamic islands or streaming components from the server?

[DavidMulder0]

The idea with the view transition API is that you first retrieve all the data and only then call startViewTransition. With some frameworks data retrieval and rendering are very cleanly separated, so implementing startViewTransition is absolutely trivial, but in modern ReactLand these things have gotten far more 'mixed up', so we probably need to 'move back in time' and unmix these things.

[AaronLayton]

You are correct @DavidMulder0 , the implementation should* be trivial, but what I mean here is that, once it gets implemented, if we show a loading skeleton straight after we click a link due to something needing to stream in, how should the view transition behave?

I expect if someone was going from an ecommerce listing page and they wanted to animate the small product image up to the large product image when they are on an individual product page then we would see flashes of the main image moving, fading into the loading skeleton, then as the rest of the page is rendered that skeleton would then fade back into the product image that we first clicked on.

Hopefully that makes sense?

Would we just not use loading skeletons in that instance etc

[DavidMulder0]

@AaronLayton Was rereading this discussion now a couple of months later, but yeah, skeleton loading and these page transitions are definitely 'competing' approaches for loading. I mean, I can imagine certain cases where hybrids make sense (e.g. loading related products on a product page), but in general I don't think the idea of in-page loading indicators makes much sense.

[renchris]

I am solely wanting to get client-side routing / soft navigation to work with NextJS App Router. The documentation says it's supported out of the box but I am not getting the intended not-full-page-refresh behaviour. Has anyone got this to work before trying to get the View Transitions to work?

[FilipChalupa]

Are you using the <Link> component instead of <a>? https://nextjs.org/docs/pages/api-reference/components/link

[renchris]

Correct, I am using the <Link/> component

[akhmadshin]

Here's my implementation of View Transition api
https://akhmadshin.dev/
I'm gonna publish source code and article soon

[AaronLayton]

Hiya @akhmadshin thanks for sharing.

Did you get the transitions working when pressing back / forward on the browser buttons? That doesn't seem to be working on your URL

[DavidMulder0]

This demo doesn't wait for network requests to complete at all... which is maybe less bad than the demos that try to do them during a transition. The most important thing with these transitions is that 1) user clicks link 2) you retrieve everything you need for next route 3) you start the transition 4) you update the DOM 5) you finish the transition. This demo instead just 1) user clicks link 2) start the transition 3) randomly mix up data retrieval, updating the DOM, finish the transition and update the rest of the DOM (depending on network speed).

[akhmadshin]

@DavidMulder0 The idea behind this demo is to reuse data as much as possible.

1. the user opens the main page and sees a list of article cards.
2. the article card consists of an image, title and description. When you click on a card, I use its data (hereinafter referred to as demo data) to display the article itself. This demo data is stored in a link component like this (<Link href="/blog/lorem-ipsum" data={{thumbnail: ..., title: ..., description: ...}}>)
   Since I don't have article content in the demo data, I'm showing a skeleton for content.
   It is important to note that when the data is loaded, the interface displayed with the demo data will not be redrawn (it will not lose the state).
3. If there is no demo data (<Link href="/blog/lorem-ipsum">), I show a skeleton for the entire page.

Imagine a e-commerce site with that optimisation. You'll be able to open product page instantly and it'll be fully functional (you'll be able to add product to card while main content is still loading).

[akhmadshin]

I created library
https://github.com/akhmadshin/next-query-glue
Now it's much easier to implement optimistic navigation. And now it's works even with middleware file.

That template already updated. And, now it's supports transition on back / forward browser buttons
https://github.com/akhmadshin/next-query-glue-starter/tree/main
Live demo:
https://next-query-glue-starter.vercel.app/

[Fakerko]

@leerob any progress on this? Will the Transition Api be implemented in Next.js soon, so it won't be behind compared to others? This discussion has been open for some time after all. Thank you for the reply.

[DavidMulder0]

Basically the thing to understand is that Next.js's approach to network requests is very 'messy' (messy in terms of being initiated from the same code which updates the DOM), thus integrating it with the view transition API in a way that works for slow network speeds is hard. In contrast, for many other frameworks each route has a clear 'retrieve data' step, which makes it trivial to integrate with the view transition API. The crucial thing for the View Transition API is that network requests and DOM updates need to be separated, something that will - I believe - require major changes in how to think about a Next.js app and a new approach to marking data to be loaded before a route is rendered. Hopefully people smarter than me can figure out how to make this work within the mental model of Next.js... but 🤷[1] . Anyway, my point is, there is good reason for Next.js to not have this, whilst some frameworks could implement this in mere hours.

Also worth noting is that most (all?) demos linked here actually either load everything at the start, or behave badly on slow connections (either awaiting network requests during the transition, or not awaiting them and having the DOM still updating after the transition), so just because lots of people claim to have made it work, doesn't mean they did. Nobody as far as I am aware figured out how to do the network requests at the start (beyond network requests loading through prefetch), whilst postponing updating the DOM.

(To me personally it feels like Next.js lost focus by focusing on the super powerful abilities that the mixing of server side and client side unlocks, but forgetting during this development the fundamentals that just because you can do amazing things by being allowed to mix, that doesn't mean that most applications should mix 😅)

[1]: Ideally the rendering code I guess would just be triggered offscreen virtually (virtual DOM and all that) and only applied during the transition, which would be weird as **** from a conceptual point of view... but at least do the trick.

[akhmadshin]

My demo working good on slow internet and doesn't prefetch anything.
https://akhmadshin.dev/

To achieve it, I implemented optimistic navigation. But to make it work I disabled default next.js client data fetching and run requests manually through react-query. It's tricky solution, but it's work.
Here's code:
https://github.com/akhmadshin/next-query-glue-starter

[DavidMulder0]

@akhmadshin Didn't look at the code, but turning off the internet on your demo just transitions to a broken page, so it's definitely not working in your demo at least (no image and no random numbers nor lorem ipsum).

[philwolstenholme]

This is now available in Webkit/Safari technical preview 192: https://webkit.org/blog/15260/release-notes-for-safari-technology-preview-192/

This will be the way of doing performant 'use the platform' route transitions and it'd be great to start to see some first-party Next.js examples that don't rely on templates.

[leerob]

👀 https://github.com/shuding/next-view-transitions

[shuding]

@DavidMulder0 Author of that lib here. IMO the behavior of "View Transition" is not well-defined in the context of Suspense and data fetching. The actual model is not just this:

Route A -> Click Link -> Fetch Data -> Render Route B
                                     ^(transition)

But sometimes like this (parallelized data fetching and rendering):

Route A -> Click Link -> Fetch Data (Streaming)                           -> Route Navigation Fully Finished
                            -> Render Component A (inside <Suspense>)
                                -> Render Component B (inside <Suspense>)
                                     -> ...

And there is no clear moment that the route navigation is done. Personally, I'm not sure what will be the correct way to model this so, I'd wait for the React team to come up with a new primitive of transition animations first. Don't think it's specifically a Next.js issue.

[AaronLayton]

Same thing mentioned here #46300 (reply in thread)

It gets complicated when we take into account all the RSC / Suspense updates

Perhaps its just as simple to have a primitive that said

Click Link -> Suspend All page updates and let RSC / Suspense fully update -> Rerender whole page

[DavidMulder0]

@shuding The problem is that for each route change you need to know which data is required. The callback of startViewTransition is for triggering the DOM update, not for triggering data requests needed for the transition. The transition needs to be able to transition to the thing you want to transition to, not to a loading state. That's why there is the hard timeout.

More generally, I have recently learned that the react team themselves has gone from believing lazy fetching in combination with prefetching is sometimes okay, to believing lazy fetching is always a bad idea. I hope I am correctly summarizing their views, but this came up when they wanted to change the default behavior of siblings in a suspense boundary.

The fundamental problem with next.js's approach is that you need to trigger the required data fetching without updating the DOM, whilst next.js does not have a standardized prefetching paradigm. Fundamentally they mixed rendering code and data fetching code like crazy for questionable benefit. (Just because you can, doesn't mean you should.)

[mattgperry]

I think all the conversation about data fetching might be irrelevant. The only lifecycle that matters here is getSnapshotBeforeUpdate. This is the singular moment before the DOM commits so wrapping any kind of state update with startViewTransition is going to be a worse user experience than firing it in getSnapshotBeforeUpdate.

And there, because startViewTransition is asynchronous, the only thing we need there is the ability to defer the update/commit until the snapshot has been taken.

[akhmadshin]

The fundamental problem with next.js's approach is that you need to trigger the required data fetching without updating the DOM, whilst next.js does not have a standardized prefetching paradigm. Fundamentally they mixed rendering code and data fetching code like crazy for questionable benefit. (Just because you can, doesn't mean you should.)

@DavidMulder0 , I separated rendering and route-data fetching with the next-query-glue library I made. It's let me skip route-data request on soft navigation and run it manually. I prefer to use tanstack-query for that.

[MikeVanoosthuyze]

Hello,

my name is Mike. I am looking for developers who have worked with the View Transitions API within Next.js. For my bachelor’s thesis, I need to reflect with external experts on the View Transitions API in Next.js. I have also created a small website in Next.js where I use the API. If there are developers who are willing to help me reflect on my project, let me know how I can get in touch. The reflection will involve answering a few questions. Hopefully, you can help me.

[renchris]

https://www.youtube.com/watch?v=eY6C_-aDdTo
https://developer.chrome.com/docs/web-platform/view-transitions/cross-document?1

Does this make it more possible for NextJS App Router to natively adopt View Page Transitions?

[Dosbodoke]

Since this API is framework agnostic I think we could make it work, I'm not sure where to implement this, maybe transforming the layout into a client component and setting the view transition there?

[akhmadshin]

I made a starter with a fully functional view transitions API (no extra library for transitions, no flushSync either).
It have next features:

• Fast navigation via optimistic UI (optimistic navigation)
• View transitions API (supports back/forward)
• Fallback for browsers without View transitions API
• SWR caching
• Image preloading
• Scroll restoration

https://github.com/akhmadshin/next-query-glue-starter

[DavidMulder0]

You disabled the next.js router prefetch, but preloading all routes is I would argue the definition of prefetching. What you call optimistic navigation is fundamentally just prefetching the partial version of the next route and lazy loading the rest. This indeed will work, but it means you are hacking stuff together and get transitions like this on slow connections in certain cases (yes, the following code path can be fixed (it happens when a browser navigation is triggered, but it shows the problem of such "hacks").

Recording.2024-10-22.132724.mp4

What you're doing is "fetch on render", where you render a loading state whilst you are waiting for the load to complete. Your loading state just happens to have enough prefetched information that transitions can look pretty decent, but you get fundamentally different behavior on a fast connection where you get (request image => click => start transition => render pretty loading state & request data => get data and image => render final page => finish transition) vs slow connections (request image => click => start transition => render pretty loading state & request data => finish transition => get data and image => render final page with manual CSS transition). The View Transitions API should remove the need for those manual non-View-Transition view transitions you added through CSS to hide that your View Transition was 'skipped' ( https://github.com/akhmadshin/next-query-glue-starter/blob/ad614c68c829cca71381f36f8b344eba9a6dd8c9/src/hocs/WithFadeTransition.tsx#L58 ).

Which is how we get to an issue I alluded to in one of my prior comments:

Having a component initiate a fetch is usually called fetch-on-render. It's the approach most of us likely use on a daily basis, but it's not the best thing you can do. Even when siblings inside the same suspense boundary are pre-rendered in parallel, you would not be able to avoid the waterfall if you have two useSuspenseQuery calls within the same react component, or if you had a parent-child relationship between components.

That is why the recommended approach by the react team is to initiate fetches earlier, e.g. in route loaders or in server components, and to have suspense only consume the resource rather than initiate the promise itself. This is usually called render-as-you-fetch.

Source: https://tkdodo.eu/blog/react-19-and-suspense-a-drama-in-3-acts

Not to say one shouldn't be allowed to disagree with what the React team recommends (after all, the React team rolled back the change that would have 'forced' everyone to fetch before you render), but I deeply believe the View Transition API highlights why mixing fetching code and render code is a bad idea.

Put differently: Skeletal loading of main pieces on the page and View transitions are competing solutions to the same problem. Mixing them is possible (as you show), but results in something... imperfect. E.g. the demo page on 4k

Recording.2024-10-22.135341.mp4

[akhmadshin]

@DavidMulder0 The flow is always the same on fast and slow networks:

1. request image =>
2. click =>
3. start transition =>
4. render pretty loading state (render route view) & finish transition
5. request data =>
6. get data and image =>
7. render rest of the article

I'm not waiting until data is loaded; I finish transition on routeChangeComplete event.
https://github.com/akhmadshin/next-query-glue-starter/blob/main/src/pages/_app.tsx#L60

I never wanted to use view transition API for the article content; in fact, I hide it until transition is finished (you can see it if you slow down animation to 10%). I think view transition should be used only for the first screen of the route view, because otherwise you get poor performance.

"What you call optimistic navigation is fundamentally just prefetching the partial version of the next route and lazy loading the rest." I'm confused; in that case, I should run fetch request two times? One for prefetching the partial version and the other on lazy loading? Why I see only 1 request in the network tab on navigation (and no requests before)?

What I call optimistic navigation is using already loaded data (without additional prefetching) as anticipated data of the route view while the actual route data is loading. And I don't prefetch a partial version of the route view. I preload the whole route view (js chunk) only once, on initial load.

WithFadeTransition.tsx file you mentioned is used for browsers that don't have view transitions API support and in some cases on navigation through history

[akhmadshin]

@DavidMulder0 Thank you for pointing out the strange skeleton during the hard reload and history navigation. I fixed it and found another small bug with scroll restoration. Made spinner which visible, while article content is loading more noticeable. Now it should look better on big monitors. I appreciate your feedback

[AaronLayton]

This is the Page Router, not the App Router right?

[akhmadshin]

Yes, this is a page router, but with a trick, it's got a next-query-glue library. That allows you to skip getServerSideProps request on soft navigation and trigger it manually with any library you like. In that starter, I use Tanstack Query. It provides granular control and adds tons of new features, making the page router feel like a completely new framework (comparison vs. default behavior).
In that video, you can see how fast it works on 3G internet (I didn't prefetch any article data):
https://www.reddit.com/r/nextjs/comments/1g6ktz2/i_made_a_starter_with_perfect_navigation/

View transitions wasn't my main goal in that starter, but I guess they look pretty slick with fast feedback provided by next-query-glue.

[akhmadshin]

I've built a next-rich-view-transitions library that let's you easily create complex view transitions in Pages router.
Demo:
https://next-rich-view-transitions.vercel.app/
More complex demo:
https://next-query-glue-starter.vercel.app/

To start the transition, call the startViewTransition method and pass the imageElement. If the opened page has an image with the same src as imageElement, the transition will happen. In addition, it automatically stores image data in sessionStorage, which enables the display of view transitions during navigation using the browser's history (back/forward).

Consider, you have a Link.tsx component like this

import NextLink from 'next/link';
import React, { useCallback } from 'react';
import { useRouter } from 'next/router';
import { startViewTransition } from 'next-rich-view-transitions';

export function Link(props: React.ComponentProps<typeof NextLink>) {
  const { href, as, replace, scroll } = props;
  const router = useRouter();

  const handleClick = useCallback(
    (e: React.MouseEvent<HTMLAnchorElement>) => {
      if (props.onClick) {
        props.onClick(e);
      }

      if ('startViewTransition' in document) {
        e.preventDefault();

        const navigate = replace ? router.replace : router.push;
        // Find an image that should start transitioning. Feel free to change that code.
        const transitionImg = e.currentTarget.querySelector<HTMLImageElement>('.transitionable-img') || document.querySelector('#transition-img');

        startViewTransition(transitionImg).then(() => {
          navigate(as || href, as, { scroll: scroll ?? true });
        });
      }
    },
    [props.onClick, href, as, replace, scroll]
  )

  return (
    <NextLink {...props} onClick={handleClick} />
  )
}

In handleClick, you await async method startViewTransition and navigate after that.