[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","routes/_layout",{"_127":128},"routes/blog/index",{"_9":10,"_11":12,"_13":12,"_14":15,"_16":17,"_18":19},"posts",[39,40],"page",1,"totalPages","tag","React","allTags",[20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,15,37,38],"total",2,"Android","Architecture","CSS","Database","Databases","Docker","Finance","Homelab","JavaScript","Linux","NestJS","Networking","Node.js","Performance","PostgreSQL","Project","Proxmox","TypeScript","Ubuntu",{"_41":95,"_43":96,"_45":97,"_47":98},{"_41":42,"_43":44,"_45":46,"_47":48},"slug","react-view-transitions-a-hands-on-look-at-the-api-that-might-finally-make-page-transitions-not-suck","meta",{"_73":74,"_75":76,"_77":78,"_79":80,"_81":82,"_83":84,"_85":86},"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. Inside, 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 remember this, 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 problems

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","headings",[49,50,51,52,53,54,55],{"_56":71,"_58":72,"_60":19},{"_56":69,"_58":70,"_60":19},{"_56":67,"_58":68,"_60":19},{"_56":65,"_58":66,"_60":19},{"_56":63,"_58":64,"_60":19},{"_56":61,"_58":62,"_60":19},{"_56":57,"_58":59,"_60":19},"id","my-conclusion","text","My conclusion","depth","animating-whole-routes","Animating whole routes","where-it-still-has-problems","Where it still has problems","what-i-liked","What I liked","using-it-with-concurrent-rendering","Using it with concurrent rendering","customizing-pseudo-elements","Customizing pseudo-elements","what-react-19-adds","What React 19 adds","title","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",[87,88,89,90,91,92,93,94],"author","Denys Bashkatov","tags",[15,28,22],"social",true,"react","view transitions","view transitions api","react 19","page transitions","animations","startViewTransition","css animations","upgrading-react-router-7-to-8-in-a-small-server-side-application",{"_73":111,"_75":112,"_77":113,"_79":114,"_81":82,"_83":115,"_85":86},"

R.O.B.O. Host, the server from the previous post, uses React Router in framework mode. This week I moved it from version 7.18 to 8.4. I was a little afraid of it, but my own code needed only about 40 lines of changes in 8 files. I am not sure that my case is typical, because I use only a part of React Router, so please read this as notes from one project.

I did not use any future flags in version 7, so all the changes came at the same moment. There were three.

The load context

The server passes the address of the device to loaders and actions. In version 7 the context was a plain object, and its type came from module augmentation of AppLoadContext:

getLoadContext: (_req, client) => ({ client: client.address }),

In version 8 it is a RouterContextProvider, and every value has its own key from createContext:

const context = new RouterContextProvider();\ncontext.set(clientContext, client.address);\nreturn context;

A route reads it with context.get(clientContext).

There was one detail which is maybe special to my build. The server entry and the React Router build are two separate bundles, and each of them has its own copy of the module with the key. So createContext would run two times, and the server and the routes would use two different keys. I keep the key on globalThis:

const CLIENT = Symbol.for("robo.clientContext");\nexport const clientContext = (globalThis[CLIENT] ??= createContext<string>());

Symbol.for gives the same symbol in both bundles. If you have one bundle, I think you will not see this problem.

meta gets loaderData

In meta, the loader's result is now loaderData and not data. The same in matches:

matches.find((m) => m?.id === "root")?.loaderData

This part was easy. After react-router typegen, tsc showed all three places as errors.

The request in a loader

This change is not visible in the types. When a person moves between pages, the browser asks only for the data, with an address like /notes.data?_routes=routes%2Fnotes. In version 7 a loader got the page address, /notes. In version 8 it gets the request as it came.

My app uses the address in two places: the next parameter for the sign-in page, and the check for the forced password change. With the raw address, after the sign-in the browser would open the data and not the page. So I take the page address back from the request:

if (url.pathname === "/_root.data") url.pathname = "/";\nelse if (url.pathname.endsWith(".data")) url.pathname = url.pathname.slice(0, -5);\nurl.searchParams.delete("_routes");\nurl.searchParams.delete("index");

The root page is a special case, /_root.data. I am not completely sure that this list is full. It works for my routes, but if somebody knows a better way, I would be glad to hear it.

How I checked it

Everything else stayed the same: routes, components, Form, useFetcher, actions, createRequestListener. The 15 end to end test suites with Playwright passed. Then I checked sign-in, page titles and the Back button on the test tablet in its own Chrome.

I think the tests were more useful than the types here. The third change would be very easy to miss without them.

\n",[99,100,101,102],{"_56":109,"_58":110,"_60":19},{"_56":107,"_58":108,"_60":19},{"_56":105,"_58":106,"_60":19},{"_56":103,"_58":104,"_60":19},"how-i-checked-it","How I checked it","the-request-in-a-loader","The request in a loader","meta-gets-loaderdata","meta gets loaderData","the-load-context","The load context","Upgrading React Router 7 to 8 in a small server side application","What I had to change in R.O.B.O. Host when I moved it from React Router 7 to 8: the load context, meta, and the request which loaders get.","2026-10-18",[116,117,118,119,120,121,122,123,124,125,126],[15,28,32],"react router 8","react router 7","react router upgrade","react router migration","routercontextprovider","createcontext","getloadcontext","meta loaderdata","node.js","typescript","side project","pages",[129],{"_41":130,"_73":131},"about","About me"]

Tech Notes

Tech tips and new discoveries

Upgrading React Router 7 to 8 in a small server side application

React View Transitions: A Hands-On Look