Yes, React’s main idea is f(state) -> UI; but what’s returned from render is a declarative specification of what the UI should be. It’s up to React (and library

Yes, React’s main idea is f(state) -> UI; but what’s returned from render is a declarative specification of what the UI should be. It’s up to React (and library authors) to make sure the UI ends up as we specify without our app logic needing to be concerned with how that happens. I view managing transition out animations for a component removed from the render tree the same way: I’m happy if the incidental complexity is encapsulated in a library (either a third party one or something I write myself), rather than spread across the whole app. There are many high quality third party tools to help with this, such as Motion’s <AnimatePresence> (https://motion.dev/docs/react-animate-presence https://motion.dev/docs/react-animate-presence). I haven’t used the library you mentioned, but it seems somewhat unmaintained and isn’t compatible with react-dom@19. First party support is coming to React with the new <ViewTransition> component (https://react.dev/reference/react/ViewTransition https://react.dev/reference/react/ViewTransition). If you insist that only the React maintainers are allowed to diverge DOM state from the render tree or write code you don’t understand, you can adopt it today from react{,-dom}@experimental. It’s been available there since April (https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#view-transitions https://react.dev/blog/2025/04/23/react-labs-view-transition...).