New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for persisting children in the DOM #62
Comments
It's really difficult to implement such a thing for the TransitionGroup since the entire trigger for whether something enter's or leaves is based around it being mounted or not. In other words the component is really a way to animate the entering or removal of things from the DOM. That said, for single items the api refactor (#24) provides a component that allows this quite easily |
I understand that this is how it currently behaves. However, I think the entering or removal of things from the DOM is built on top of a lower-level system, which is a state machine with four states:
These four states can be mapped to whatever we need, including the notion of "entering" and "leaving", as well as triggers for mounting/unmounting.
Oh yeah? I read through that code, but maybe I missed it – which component are you referring to? |
And again for groups of items it probably won't happen, the state management would be really crazy and maybe impossible to do correctly, or simply enough for the API to work |
Right, I don't think it's that useful for groups.
I linked to this in the opening comment issue as a possibility, but in the linked source it looks like it already does a mapping between the states I described above and unmounting. The link in the first comment of this issue points to the code where it equates the "UNMOUNTED" state with the children being removed from the DOM. To solve this issue, the transition component would need 4 states that do not always map to mounting/unmounting. Am I missing something in the source? |
Transition already does this. It only unmounts when you tell it too. Otherwise it just toggles the enter and exit animation |
Oh ok, then awesome! 👌 |
Could we close this? |
I think so! Thanks. |
Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Transitioning out always removes children from the DOM.
For lists of items, you typically do want to remove and add things to the DOM as the things transition, so the current behavior of the transition group makes sense there.
However, when using the TransitionGroup for a single item, it's more performant to just leave the thing in the DO, while reducing their opacity to 0 and turning off pointer-events. Then, you can do transitions for things like modals without any reflows or paints. There are a handful of common one-off DOM elements that this is useful for: modals, dropdowns, flyouts, tooltips, etc. Basically, anything that is not in a list that has animated entries and exits.
For desktop apps, unmounting and re-mounting might not matter too much, but when developing with slow mobile phones in mind, I do my best to reduce reflows and paints.
Is there any interest in supporting this here? I took a quick look at the big refactor in #24, and it doesn't seem to support this, as it appears to always unmount by default.
One way to implement this would be with a Boolean prop that tells the transition group whether the child should remain in the DOM, or be removed. It could unmount the children by default for backwards compatible.
Right now, I use a modified TransitionGroup for these things, and then the regular TransitionGroup for lists. It'd be cool to use just one.
What do folks think? Out of scope for the TransitionGroup? Maybe worth it?
The text was updated successfully, but these errors were encountered: