Add notes for March 31

[gaearon]

No description provided.

[bigblind]

Just wanted to say I love this repo. I love how open you guys are with the governance of this project.

[baptistemanson]

What an awesome governance! What is Internal Facebook Infra? Is it a team @facebook?

[sophiebits]

Just "internal Facebook infrastructure", by which we mean that we're looking at trying JavaScript styles on the facebook.com website itself (or other Facebook-owned websites which use the same stack). Not a separate team. :)

[gaearon]

I must be picking up the jargon 😧 . Will try to explain FB-specific terms better!

[cheapsteak]

ReactTransitionGroup is really complicated

Is this because animation is inherently complicated to deal with, or is it something that shouldn't be too hard to simplify but no one's yet had the time?

ReactTransitionGroup is also not as robust as I think it should be.

It's missing the ability to

• Specify transition order
  Transitions currently can only happen simultaneously, there's no way to tell the "enter" animation to wait for the "leave" animation to finish first.
• Interrupt an animation
  A Component in the process of a long enter transition won't start its leave animation until the enter animation finishes, and vice versa. This creates a poor experience for page transitions and carousels where the transition group might update frequently from the user rapidly clicking something

I've tried my hand at adding those in but that added 100+ more lines of code and a dependency on Promises :(

It would be nice if those features were added (or roadmapped) into the official addon if there is to be a big rewrite (especially the interruptibility)

[gaearon]

@cheapsteak

I think there are a couple of things that make TransitionGroup complicated:

• It relies on transition events which are known to be unreliable. We introduced timeout props to alleviate that, so at least part of the problem is solved.
• It is a complicated problem per se. For example, merging algorithm can be written in different ways. Currently we always prepend new items but this causes problem because people can’t rely on a stable order and some people want items to be appended instead (Preserve order in mergeChildMappings facebook/react#6149). One of the first implementations of transition group used a more smart merge algorithm based on longest common subsequence but it was too slow. This means that the algorithm should probably be pluggable but that expands the public API.
• We can’t really expand the public API because we don’t use this component internally much. For this reason it’s very hard to tell if any changes we make are going to be great, or if they are going to break some use cases we didn’t think about, or are just a bad API.
• People want TransitionGroup to behave slightly differently depending on their use case (this includes interruption, see Accommodate interruption of transitions in ReactTransitionGroup facebook/react#5989). However such changes are often breaking but it is difficult for us to assess whether this is something most people would want or not.
• Finally, it has some quirks in design (such as “custom” lifecycle methods) which causes confusion when used together with higher order components or functional components. It doesn’t seem like this particular API is the exact API we want to end up with for animating children.

I hope this gives you an idea of the challenges with TransitionGroup. There is definitely not going to be a roadmap, or a big rewrite for it. As we say in the notes, we don’t use it, so we should just hand it over to someone who does. They can increment the version number and then work with the community to make it better. At this point I would expect breaking changes but that’s the point: if you’re satisfied by what we have right now, just stay on that version or create your own fork.

[donabrams]

Some thoughts on ReactTransitionGroup:

ReactTransitionGroup has the same problem as Promises; it has an underlying state machine and people always find needs for new states and transitions. Instead of trying to design a ReactTransitionGroup state machine that handles all cases, I'd suggest designing a newer ReactTransitionGroup around an arbitrary state machine.

Libraries/APIs worth mentioning: https://github.com/aasm/aasm, https://github.com/machty/ember-concurrency, and https://github.com/yelouafi/redux-saga.

A future "ReactTransitionGroup" could then be a tiny css class layer constructed via conventions from a state machine.

[vitorbal]

How about a dedicated section where all the FB-specific / React-specific terms are explained? Could be an "add more terms as you go" approach, where terms get added once people ask about it.

[gaearon]

How about a dedicated section where all the FB-specific / React-specific terms are explained?

We could do it if it’s a repeated problem.