View Transitions in React: A New Era of Seamless UI

Smooth UI isn't just an eye candy, it's how the users decide if your app feels modern. Hi, I'm Samuel Ouyang, a founding engineer at AI Startups. Today I will show you how to use the React 19 and the View Transition API to unlock the seamless UI without the pain. It features how the React moves. So why do animations in React feel broken? First of all, the routing changes are juggling. There are zero continuities. So then we move to the complex third-party animation libraries. But this adds the complexity, bundle size, and boilerplate. When that is not enough, and then we're trying the fragile DOM hacks, that results in the SSR and the RLC to be broken. And a smooth UI always feels like fighting React instead of working with that.

So here's the old way of doing the transitions. The old transition technique just does not scale. The animation, the layout, resulting in the unpredictable shifts. Routing changes, introducing loading flickers, and the SSR leads to a hydration mismatch. And patching these issues kills the performance. So that means more code, more hacks, still bad UX. Then we have the frame motions. Frame motions actually was a huge step forward, but even that, it has limits. First of all, we need to add extra code to almost every component. There's no native router transitions. And also, it increases the bundle size, and does not support well with SSR and streaming.

So here comes the View Transition API. View Transition API is a native browser feature that built to solve these problems. So how does it work? First of all, it snapshots the DOM before and after. And then the browser animates between them. No manual differing, and it handles the route updates and the full page changes. For the first time, smooth transitions are built into the platform. Then the React 19 embraces this API with the View Transition component. View Transition component is experimental, but it makes the transitions declarative and native to React. It integrated with the routings, so route.push animates the page automatically.

It works with SSR and RSC. And finally, it has the View Transition components that could work with the View Transition API. But it also has the limitations. First of all, it is a wrapper. It means that we need to wrap the JSX trees for almost every place we need to perform the view transitions. And there's no auto route handling. It means that if we're doing the router with the loadings, or we need to handle some complex routing based on the conditions, we have to wrap it carefully. And that is error-prone.

Secondly, it's hard to do with the suspense and SSR because the View Transition is a client-side API. So it means that SSR and the streaming are easy to get flashed, double rendered, and mismatched. If we start the transition at the wrong time, that also requires that you wrap the correct components at the right time using the React 19's View Transition wrapper. Then I introduce the Use View Transition custom hook that I created. It perfectly solves the problems that it works with both routing, state, and suspense.

For example, like the auto route handling. We can put it directly in the triggers of doing the routings, for example, doing the navigations, and it could also handle the complex nested routes. And it's also SSR safe and fallback to a concurrent friendly with a start transition React Native API. React gave us the engine, and I built the steering wheel to introduce the flexibilities to working with the View Transition API. Here's my code. Here's what my code looks like. Besides the declarations and other work, the real code actually just has the 10 lines.

So on the left side is the custom hook implementations. On the right side is how to use that custom hook. On the left side, basically, is first of all, feature detect the browser APIs, and we could detect that. And they were just around the native start view transition. And they use the flash sync to ensure that the DOM is synced correctly to prevent any unexpected flashes. And if the browser cannot find the start view transition, gracefully fallback with non-urgent scheduling React with start transition is concurrently non-blocking operations that make the transition still smoothly without the view transition.

So here's a quick demo of doing that. I'm just sharing my screen. Let me just pull off the website thing here. Here's my API. Here's the website I created using the custom hook that I created. First of all, I implemented multiple implementations, including route changes, layout changes, and click events. Regarding the route change, you can see that we have smooth transitions using the hook I created called useViewTransition. Regarding the panel transitions, we changed from the grid to list and the list to grid. You will see the transitions pretty smoothly. And the third actually is the click events, means that we just animate the flippings using the view transitions. And the same for this as well.

For example, I'm clicking hide, hide, and hide, and click show all. You see that the transition is pretty smoothly with the custom hook that I created. And the last but not least is the list reordering. This already, for example, has the five items with different colors. It means that we no longer have the hydration or flicker issues because this spans well transitions with the safe fallback using the start transition API. So let's go to the next one.

And then reset ordering. You'll see that the transition actually is pretty smoothly without any third-party code. Just using the custom hook and also the view transition API, the browser native view transition API, and also the start transition API that created by React.

So how does the view transition API work on the hood? First of all, the browsers capture the current DOM state, change the image, and then the React scheduled updates use the start transitions and the browser smoothly animates from the old to the new state. So it means that we no longer have the hydration or flicker issues because this spans well transitions with the safe fallback using the start transition API. Yes.

So when should we use the view transition? And when should we not? The perfect use case is what I just demonstrated, like the raw changes, card animations, tab switches, layout changes. But it is not ideal for the high-frequency streaming. For example, the live chats are streaming data real-time updates. And also, of course, it does not support some of the browsers. And I will mention that later in the next slide. And also the complex data management, for example, real-time data merge, and also the hover and focus that will result in the flickers.

Regarding the performance capabilities, it works with the Chrome, Edge, and the Safari. And they're all in a stable status. But for Firefox, it's still in development, but it will be coming soon this year. I encourage everyone to use the start view transitions. It avoids DOM hacks and also to try to handle the different types of the animations. For example, the route animation and also the list of reordering that's with clean code without DOM hacks.