Skip to content
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

Closed
jamesplease opened this issue May 19, 2017 · 8 comments
Closed

Support for persisting children in the DOM #62

jamesplease opened this issue May 19, 2017 · 8 comments

Comments

@jamesplease
Copy link
Contributor

jamesplease commented May 19, 2017

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?

@jquense
Copy link
Collaborator

jquense commented May 19, 2017

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

@jamesplease
Copy link
Contributor Author

In other words the component is really a way to animate the entering or removal of things from the DOM.

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:

out, coming in, in, going out

These four states can be mapped to whatever we need, including the notion of "entering" and "leaving", as well as triggers for mounting/unmounting.

provides a component that allows this quite easily

Oh yeah? I read through that code, but maybe I missed it – which component are you referring to?

@jquense
Copy link
Collaborator

jquense commented May 19, 2017

Transitionis the component you want.

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

@jamesplease
Copy link
Contributor Author

jamesplease commented May 19, 2017

And again for groups of items it probably won't happen

Right, I don't think it's that useful for groups.

Transitionis the component you want.

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?

@jquense
Copy link
Collaborator

jquense commented May 20, 2017

Transition already does this. It only unmounts when you tell it too. Otherwise it just toggles the enter and exit animation

@jamesplease
Copy link
Contributor Author

Oh ok, then awesome! 👌

@koba04
Copy link
Member

koba04 commented Nov 25, 2017

Could we close this?

@taion
Copy link
Member

taion commented Nov 25, 2017

I think so! Thanks.

@taion taion closed this as completed Nov 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants