AnimateView allows you to animate elements between different views using the browser's native View Transition API.
It's a 3kb component built on top of Motion's mini animate() function and React's ViewTransition component, providing a simple API for adding values like clipPath and configuring animations with Motion's transitions, including springs.
It's possible to write specific animations for when elements enter and exit the DOM, when they update, or when performing shared element animations.
Now, when show is changed within a React startTransition, the element will perform the browser's default fade in/out animation as it enters and leaves the DOM.
startTransition(()=>setShow(!show))
startTransition(()=>setShow(!show))
startTransition(()=>setShow(!show))
View transitions will only trigger when state changes are wrapped in startTransition.
AnimateView is built on Motion's mini animate() function for a tiny filesize. Therefore, spring must be explicitly imported from "motion" and passed to the type transition option.
By default, AnimateView will animate elements using the browser's default opacity animation. But, if you set your own values within enter, exit, share or update then this crossfade will be disabled.
Elements wrapped in AnimateView will also animate whenever their content or visual styles change, crossfading between the two views. This animation can be customised with the update prop.
When an AnimateView component with a name prop exits the DOM, and another one with the same name enters it within the same transition, the two elements will perform a shared element animation.
enter, exit, share and update props can all resolve dynamically, with a list of values set via addTransitionType. You can use this information to generate different animations.
<ViewTransition> creates an image that can be moved around, scaled and cross-faded. Unlike Layout Animations you may have seen in React Native or Motion, this means that not every individual Element inside of it animates its position. This can lead to better performance and a more continuous feeling, smooth animation compared to animating every individual piece.
Neither of these claims are true.
From our own stress test benchmarking, creating image bitmaps and constructing a pseudo-DOM is more memory intensive and slower than the equivalent layout measurements used by Motion's layout animations.
The claim of "a more continuous feeling" is also not right. Layout animations are **interruptible**, which means you can change direction mid-animation and they respond immediately. View transitions are **not interruptible**, meaning they must complete before a new transition can begin. This makes layout animations a far better candidate for micro-interactions where responsiveness matters.
View transitions are best suited for **page-level transitions** (route changes, full-view swaps) where the non-interruptible nature is acceptable and the snapshot-based approach avoids complex per-element coordination.
Unlock the full vault of 330+ Motion examples, 100+ tutorials, premium APIs, private Discord and GitHub, and powerful Motion Studio animation editing tools for your IDE.