[{"_1":2,"_60":-5,"_61":-5},"loaderData",{"_3":4,"_12":13},"routes/_layout",{"_5":6},"pages",[7],{"_8":9,"_10":11},"slug","about","title","What's going on here?","routes/blog/index",{"_14":15,"_46":47,"_48":47,"_49":41,"_50":51,"_59":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 practical walkthrough of the View Transitions API in React — what works, what does not work, and whether it is ready for real projects.","date","2026-03-16","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","

For years, smooth page transitions on the web have been a pain. You either reached for heavyweight animation libraries, hacked together CSS transitions with state juggling, or just accepted the hard cut between views. Native mobile apps had us beat — swipe between screens and everything morphs naturally.

The View Transitions API changes that. And with React starting to integrate support for it, there's finally a path to fluid transitions without pulling in half of npm. I've been experimenting with it, and here's what I've found.

What the View Transitions API Actually Does

At its core, the API captures a "before" snapshot of the DOM, lets you make changes, then animates between the old and new states. The browser handles the heavy lifting — it literally takes screenshots of elements, cross-fades them, and interpolates positions.

The simplest vanilla usage:

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

The browser snapshots the old state, runs your callback, snapshots the new state, then animates between them. No keyframes to write, no FLIP calculations, no layout thrashing. It just works.

Bringing It Into React

React 19 introduced the <ViewTransition> component and integrated startViewTransition into its rendering pipeline. This is where things get interesting — React can now coordinate its state updates with the browser's transition mechanism.

Here's a basic example using React Router and view transitions:

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 key — when React sees matching ViewTransition names across navigations, it morphs one into the other. The thumbnail on the list page smoothly expands into the hero image on the detail page. No animation code needed.

Controlling the Animation with CSS

The default cross-fade is fine, but you'll probably want more control. The API exposes pseudo-elements you can style:

/* 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}

You can also use view-transition-class to group elements and animate them together with shared CSS rules, rather than writing per-element styles.

Using startTransition Under the Hood

React's integration ties view transitions to its concurrent rendering model. When you trigger a state update inside a transition, React batches the DOM changes and wraps them in startViewTransition for you. This means you can use useTransition alongside view transitions:

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}

The content swap gets animated automatically. React's concurrent rendering ensures the new content is ready before the transition starts, so you don't get a flash of incomplete UI.

What Works Well

Zero-dependency animations. No Framer Motion, no GSAP, no React Spring. The browser handles it natively, and the performance is excellent because it's composited at the GPU level.

Shared element transitions are genuinely impressive. The list-to-detail pattern — where a card morphs into a full page — looks slick with very little code. This used to require significant effort.

Progressive enhancement is built in. If the browser doesn't support the API, nothing breaks. The transition just doesn't happen, and users see the standard instant swap. You can detect support easily:

const supportsViewTransitions = 'startViewTransition' in document;

What Needs Work

Browser support is the elephant in the room. Cross-document view transitions (MPA) landed in Chrome and Edge but Firefox and Safari are still catching up. Same-document transitions have broader support, but you need to check your audience.

Complex transitions get finicky fast. Once you go beyond simple fades and morphs, you're back to writing detailed CSS animations. The API gives you the hooks, but it doesn't magically handle every case. Animations where elements change size, position, and content simultaneously can produce visual artifacts.

Debugging is rough. When a transition doesn't look right, figuring out why is harder than it should be. The pseudo-element approach means you can't easily inspect the transition state in DevTools the way you would a normal element.

React's integration is still evolving. The <ViewTransition> component works, but the ergonomics around things like conditional transitions or transition groups could be smoother. The API surface might change.

A Practical Pattern: Route Transitions

Here's a more complete pattern 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}

Add some CSS and every route change gets a smooth 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}

Should You Use It Today?

If you're building a project where Chrome/Edge dominance is fine (internal tools, Electron apps, PWAs for a known audience), absolutely. The API is stable enough for same-document transitions, and the results are noticeably better than no transitions at all.

For public-facing sites where you need broad browser support, treat it as progressive enhancement. Add view transitions knowing they'll delight Chrome users and gracefully degrade elsewhere.

For production apps with complex animation requirements, keep your animation library for now. The View Transitions API handles the common cases well but isn't a replacement for something like Framer Motion when you need fine-grained control over gesture-driven animations or spring physics.

The direction is right though. Browser-native transitions with framework integration is exactly where this should be heading. The less JavaScript we ship for visual polish, the better.

\n","page",1,"totalPages","tag","allTags",[52,41,53,54,40,55,56,39,57,58],"Architecture","Docker","Homelab","Linux","Node.js","TypeScript","Ubuntu","total","actionData","errors"]

Tech Notes

Tech tips and new discoveries