Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

@timfuhrmann thanks for opening this up! I can definitely see how this nuance of the current Modal is a hassle.

I assume the component is mounted incoherent to the open state for the enter/exit animation.

Yes, I think the animation is the sole reason.

Hence I would suggest to utilise the HTML element's animation event listeners to delay the unmount until the animation has finished.

We've recently refactored Modal behind a feature flag to use the native <dialog> element. It uses a new internal Dialog component that uses @starting-style for the animations, which supports transitioning elements on DOM addition and removal. We've done a similar refactor for ComposedModal as well.

I think this should make it so you can conditionally render the modal and still have animations work. I'm curious though if you'd agree based on your experience.

I'm not opposed to exploring a solution similar to what Radix or Spectrum are doing, but we might not need it if this solves for all the use cases you mention. What do you think?

@tay1orjones Thanks for getting back to me on this so fast!

It uses a new internal Dialog component that uses @starting-style for the animations, which supports transitioning elements on DOM addition and removal.

I am not 100% familiar with the new Dialog API yet, but from what I can see and after brief testing the unmount unfortunately still has to be delayed for the exit animation to not be interrupted. The docs example's JavaScript snippet also shows a setTimeout to defer said removal. My guess is that a solution similar to what Radix or Spectrum are doing is still necessary to make this work.

Happy to do a little more research on this or help explore potential solutions!