feat: Support CSS transitions in RAC #7488
Conversation
| isEntering: 250, | ||
| transition: '[opacity, translate]', | ||
| transitionDuration: { | ||
| default: 250, |
There was a problem hiding this comment.
A bit weird that this is not symmetric with isExiting. isEntering won't work because it is only applied for a single frame. With CSS transitions, isEntering is more like "starting style".
devongovett
force-pushed
the
rac-css-transition
branch
from
fa5755c to
e74380e
Compare
The potential confusion is that it does not wait for transitions in the entering state. The entering state acts as the starting state of the transition, then it is removed causing the transition to the default state. So while the transition state is happening (I would call that entering), |
|
Ah, I see. I got hit by the confusion. It doesn't look like we lose the ability to have asymmetrical animations? so I'm ok with it, I think we'll just need to document it much like CSSTransition did and explain what the base/to states are. |
Fixes #6225, closes #5627
For discussion. This adds support for CSS transitions to RAC for entry and exit animations, in addition to the existing support for keyframe animations. Transitions have the benefit that they are interruptible. I noticed in the ActionBar PR that if you clicked fast enough you could see it "jump". That's because when a keyframe animation is interrupted, it jumps to the end, and then the next animation starts. With CSS transitions, the next animation continues from where the previous one left off instead, avoiding this problem.
Currently there is no API change needed for this:
data-entering– waits for keyframe animations to complete, but does not wait for css transitions. For CSS transitions, the starting styles can be applied here, and after one frame, they are removed so that the transition to the default style occurs.data-exiting– now waits for css transitions as well.I'm not sure if this is confusing or not, or whether we should introduce another data attribute instead.