Most active commenters
  • jitl(3)
  • chamomeal(3)

←back to thread

205 points samspenc | 16 comments | | HN request time: 1.379s | source | bottom
Show context
adithyassekhar ◴[] No.45146246[source]
This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that.

Similarly, adding a modal like this

{isOpen && <Modal isOpen={isOpen} onClose={onClose} />}

instead of

<Modal isOpen={isOpen} onClose={onClose} />

Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.

replies(4): >>45146382 #>>45146410 #>>45147091 #>>45147510 #
1. aiiizzz ◴[] No.45147091[source]
That breaks the out transition.
replies(8): >>45147226 #>>45147342 #>>45147669 #>>45148400 #>>45148647 #>>45150589 #>>45150865 #>>45153296 #
2. amatecha ◴[] No.45147226[source]
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. :)
replies(1): >>45151902 #
3. akie ◴[] No.45147342[source]
Unless you set `isOpen` only when the transition has ended
replies(1): >>45147405 #
4. debugnik ◴[] No.45147405[source]
Isn't isOpen = false what triggers the transition in the first place here?
5. abdusco ◴[] No.45147669[source]
Even when using view transitions?

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

replies(1): >>45147893 #
6. csande17 ◴[] No.45147893[source]
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.
7. btown ◴[] No.45148400[source]
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!
8. zarzavat ◴[] No.45148647[source]
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.
9. adithyassekhar ◴[] No.45150589[source]
Good point, luckily there are no transitions for modals in this project.
10. jitl ◴[] No.45150865[source]
You should rethink your modal system if removing the controller component from the render tree doesn’t transition out
replies(1): >>45151921 #
11. chamomeal ◴[] No.45151902[source]
The designers don’t want to break the out transition, and the PM wants whatever the designer wants
12. chamomeal ◴[] No.45151921[source]
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

replies(1): >>45152523 #
13. jitl ◴[] No.45152523{3}[source]
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...).

replies(1): >>45164508 #
14. socalgal2 ◴[] No.45153296[source]
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.
15. jitl ◴[] No.45164508{4}[source]
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?...

replies(1): >>45169343 #
16. chamomeal ◴[] No.45169343{5}[source]
awesome thanks!!

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