I remember solving this problem before. These are both global components, so you create a single global instance and control them with a global context or function.

You basically have a global part of the component and a local part. The global part is what actually gets rendered when necessary and manages current state, the local part defines what content will be rendered inside the global part for a particular trigger and interacts with the global part when a trigger condition happens (eg hover timeout for a tooltip).

React devs re-discovering DOM manipulation... SMH.

This is, in general, the idea that is being solved by native interaction with the DOM. It stores the graphic, so it doesn't have to be re-instated every time. Gets hidden with "display:none" or something. When it needs to display something, just the content gets swapped and the object gets 'unhidden'.

Good luck.

The post you’re replying to is saying they went FROM always having the component mounted (at least in the component tree if not in the DOM as display:hidden), TO only mounting the component when it needs to be open. They moved from the way you’re talking about, to creating the component/DOM nodes only when needed.

Excessive nodes - hidden or not - cost memory. On midrange Android it’s scarce and even if you’re not pushing against overall device memory limit, the system is more likely to kill your tab in the background if you’ve got a lot going on.

Especially when you know the user won't be opening half of those. I did'nt use a global one because the modals themselves have some complex logic inside.

"Devs use React because they how to use the web platform, here's how to do it right" and then posts a vanilla solution that doesn't solve understand or solve the problem. Tale as old as time. Bonus points if covering the edge cases in the vanilla solution and making it work for a second component would involve a tiny homegrown reimplentation of most of React anyway.

In the Blazor space we use factories/managers to spawn new instances of a modal/tooltip instead of having something idle waiting for activation.

The tradeoff is for more complicated components, first renders can be slower.

That breaks the out transition.

So, win-win? I want a modal to get out of the way as fast as possible, any fade/transition animations are keeping me from what I want to look at. :)

The designers don’t want to break the out transition, and the PM wants whatever the designer wants

Unless you set `isOpen` only when the transition has ended

Isn't isOpen = false what triggers the transition in the first place here?

Even when using view transitions?

https://developer.mozilla.org/en-US/docs/Web/CSS/@starting-s...

The "Transitioning elements on DOM addition and removal" example in that article uses a setTimeout() to wait an extra 1000 milliseconds before removing the element from the DOM. If you immediately remove the element from the DOM (like would usually happen if you do {isOpen && <Modal />} in React), it'll vanish immediately and won't have time to play the transition.

You can create a ref that stores whether isOpen has ever been true, and condition on that, letting you lazily initialize the Modal and its contents while preserving out transitions. I’m honestly surprised this isn’t recommended a lot more often!

Good. Transitions are meant to serve a purpose, showing what came from where. A modal doesn't need a transition, it should just disappear instantly. Like closing a window. The user is not helped by animating that something disappears when they close it, they already knew that.

Good point, luckily there are no transitions for modals in this project.

You should rethink your modal system if removing the controller component from the render tree doesn’t transition out

I mean in react if it’s gone from the render tree, it’s gone. I know there are libs like transition-group but I honestly don’t understand how they work.

And the “react way” is to have the UI reflect state. If the state says the modal is not being rendered, it should not be rendered

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). 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).

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-transition...).

For anyone curious, here's a proof-of-concept of how to implement a <Modal> that manages its own transition out when it's unmounted using just ReactDOM.createPortal and React.useLayoutEffect.

https://stackblitz.com/edit/react-modal-with-transition-out?...

awesome thanks!!

Ok it all makes sense now. I’d forgotten about useLayoutEffect. Haven’t had to write much react recently.

You can add some TransitionManager that uses a bool prop whether or not to render its children and when the prop goes from true to false, keeps rendering its children for some amount of time.

Alternatively, how many modals can be open at any given time? And is it a floating element? May be an option to make it a global single instance thing then, set the content when needed. Allows for in/out transitions, too, as another commenter pointed out. See also "Portals" in React.

There is only one. Won't contexts cause rerenders through the tree? We already use portals. It's just each modal have complex logic inside them that they're their own component.