[{"_1":2,"_67":-5,"_68":-5},"loaderData",{"_3":4,"_12":13},"routes/_layout",{"_5":6},"pages",[7],{"_8":9,"_10":11},"slug","about","title","About me","routes/blog/index",{"_14":15,"_46":47,"_48":47,"_49":41,"_50":51,"_66":47},"posts",[16],{"_8":17,"_18":19,"_44":45},"react-view-transitions-a-hands-on-look-at-the-api-that-might-finally-make-page-transitions-not-suck","meta",{"_10":20,"_21":22,"_23":24,"_25":26,"_35":36,"_37":38,"_42":43},"React View Transitions: A Hands-On Look","description","A look at the View Transitions API in React: how it works, where it has problems, and whether it is ready for real projects.","date","2026-02-04","keywords",[27,28,29,30,31,32,33,34],"react","view transitions","view transitions api","react 19","page transitions","animations","startViewTransition","css animations","author","Denys Bashkatov","tags",[39,40,41],"React","JavaScript","CSS","social",true,"html","

The View Transitions API gives page transitions to the browser, and React 19 has started to wire it into its own renderer. In this post I want to look at how it works and where it still has problems. Under the hood the API is simple enough: it makes a screenshot of the page, then it lets you change the DOM however you want, and after this it makes a second screenshot and animates between the two images. The important detail here is that you don't animate the real elements but only the pictures of them, and if you keep this in mind it explains most of the strange things which happen later.

Here is the plain version, without any framework:

document.startViewTransition(() => {\n  // Update the DOM however you want\n  document.querySelector('.content').innerHTML = newContent;\n});

The browser takes a snapshot of the old state, then it runs your callback and takes a snapshot of the new state, and after that it animates the difference between them.

What React 19 adds

React 19 adds a <ViewTransition> component. It also moves startViewTransition into its render pipeline. So a React state update and the browser transition stay in sync.

Here is a small example with React Router:

import { ViewTransition } from 'react';\nimport { useNavigate } from 'react-router-dom';\n\nfunction PostCard({ post }) {\n  const navigate = useNavigate();\n\n  return (\n    <ViewTransition name={`post-${post.id}`}>\n      <article\n        onClick={() => navigate(`/post/${post.id}`)}\n        style={{ cursor: 'pointer' }}\n      >\n        <img src={post.thumbnail} alt={post.title} />\n        <h3>{post.title}</h3>\n      </article>\n    </ViewTransition>\n  );\n}\n\nfunction PostDetail({ post }) {\n  return (\n    <ViewTransition name={`post-${post.id}`}>\n      <article>\n        <img src={post.image} alt={post.title} />\n        <h1>{post.title}</h1>\n        <p>{post.body}</p>\n      </article>\n    </ViewTransition>\n  );\n}

The name prop is the part which does the real work. Two ViewTransition elements get the same name across a navigation. Then the browser animates one into the other. As a result the thumbnail on the list page grows into the main image on the detail page. And you didn't write any animation code for this.

Customizing pseudo-elements

The default cross-fade is good enough in many cases. But sometimes you need something different. For this the API gives you a set of pseudo-elements:

/* Customize the transition duration */\n::view-transition-old(*),\n::view-transition-new(*) {\n  animation-duration: 300ms;\n}\n\n/* Make a specific element slide instead of fade */\n::view-transition-old(post-hero) {\n  animation: slide-out 250ms ease-in;\n}\n\n::view-transition-new(post-hero) {\n  animation: slide-in 250ms ease-out;\n}\n\n@keyframes slide-out {\n  to { transform: translateX(-100%); opacity: 0; }\n}\n\n@keyframes slide-in {\n  from { transform: translateX(100%); opacity: 0; }\n}

Using it with concurrent rendering

Transitions are also connected to React's concurrent rendering. Updates inside a transition are batched and wrapped in startViewTransition automatically:

import { useTransition } from 'react';\n\nfunction Tabs({ tabs }) {\n  const [activeTab, setActiveTab] = useState(0);\n  const [isPending, startTransition] = useTransition();\n\n  return (\n    <div>\n      <nav>\n        {tabs.map((tab, i) => (\n          <button\n            key={i}\n            onClick={() => {\n              startTransition(() => setActiveTab(i));\n            }}\n          >\n            {tab.label}\n          </button>\n        ))}\n      </nav>\n      <ViewTransition>\n        <div className={isPending ? 'loading' : ''}>\n          {tabs[activeTab].content}\n        </div>\n      </ViewTransition>\n    </div>\n  );\n}

React prepares the new content before it starts the transition. So you avoid the flash of half-rendered UI. Normally you get this flash when you do it manually.

What I liked

The main advantage is that it is native. The compositing runs on the GPU, not on the main thread. So the animation stays smooth, even when React is busy with a heavy render. The most interesting case is the shared element. A thumbnail in a list grows into the full image on the detail page. And the only thing you write is the same name on both sides. You also don't need to write a fallback. In a browser without the API the transition simply does nothing. The content is just swapped instantly. One line is enough to detect this:

const supportsViewTransitions = 'startViewTransition' in document;

Where it still has rough edges

The first thing to know is that you return to hand-written CSS very quick. As soon as you go past a simple fade, you write keyframes by hand again.

A more subtle problem appears when an element changes size and aspect ratio at the same time. Imagine a square thumbnail and a wider detail image with the same view-transition-name. The browser interpolates width and height separately. So for a short moment the image visibly stretches, before it reaches the correct shape. The usual solution is to stop the browser from interpolating the box. You let object-fit do the crop instead:

::view-transition-old(photo),\n::view-transition-new(photo) {\n  height: 100%;\n  width: 100%;\n  object-fit: cover;\n}

In general, you animate screenshots. So the worst problems appear exactly where size, position and content change all at the same time.

Debugging is also not comfortable. The pseudo-elements are not normal DOM nodes. So DevTools can't show you the transition state during the animation. In the end you set animation-duration: 5s only in order to see what actually happens. Also React's own API is still changing. <ViewTransition> works today. But I wouldn't write a tutorial about conditional transitions or transition groups yet. I expect that this API will change again, before it becomes stable.

A few words about browser support. Same-document transitions are available in Chrome already for a while, so you can rely on them. Cross-document transitions (the MPA case) came later, only in recent Chrome and Edge. Firefox and Safari are still behind. So if you start today, start with same-document.

Animating whole routes

Here is a more complete example for animating between routes:

import { ViewTransition } from 'react';\nimport { Routes, Route, useLocation } from 'react-router-dom';\n\nfunction App() {\n  const location = useLocation();\n\n  return (\n    <ViewTransition>\n      <Routes location={location}>\n        <Route path="/" element={<Home />} />\n        <Route path="/about" element={<About />} />\n        <Route path="/post/:id" element={<Post />} />\n      </Routes>\n    </ViewTransition>\n  );\n}

With a little CSS every route change also receives a transition:

::view-transition-old(root) {\n  animation: fade-and-scale-out 200ms ease-in forwards;\n}\n\n::view-transition-new(root) {\n  animation: fade-and-scale-in 200ms ease-out forwards;\n}\n\n@keyframes fade-and-scale-out {\n  to {\n    opacity: 0;\n    transform: scale(0.95);\n  }\n}\n\n@keyframes fade-and-scale-in {\n  from {\n    opacity: 0;\n    transform: scale(1.05);\n  }\n}

My conclusion

Same-document transitions are the part which I would use right now without much hesitation. They're stable enough. And in the worst case, if something is wrong, the page simply swaps the content instead of animating it. So nobody sees a broken screen. Cross-document transitions I prefer to avoid until Safari ships them. The whole point of this API is that it is almost effortless. And to build a second transition path, only for the browsers which don't support it yet, removes this advantage.

So as a conclusion, my answer is simple: yes for any place where I control the browser, and not yet for the open web. Safari needs one or two more releases.

\n","page",1,"totalPages","tag","allTags",[52,41,53,54,55,56,57,40,58,59,60,61,62,63,39,64,65],"Architecture","Database","Databases","Docker","Finance","Homelab","Linux","Networking","Node.js","Performance","PostgreSQL","Project","TypeScript","Ubuntu","total","actionData","errors"]

Tech Notes

Tech tips and new discoveries