-
Notifications
You must be signed in to change notification settings - Fork 651
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
Refactor API #24
Refactor API #24
Conversation
|
I'd prefer if transitions, especially transitioning out (since you can do transitioning in currently), was part of the Component life cycle so a component could handle its own transitions. |
@BowserKingKoopa ideally that would be great. Unfortunately there isn't any real way to do that, since unmounting is not asynchronous, and we cannot do it over time, which is part of why this s so complicated to do in React in the first place :) The idea tho behind this Api is that you can get pretty close to that, by defining your own Transition component that is in charge of doing the actual transition, and it exposes a lot of hooks for each transition state change. |
a689d6c
to
78a2cfe
Compare
I guess it's a good direction. Reusable animations are a big plus. And separating appear from enter animations seems not necessary. |
* Incorporated development + production builds into /dist (#64) and updated Readme to include CDN/External information. * Dropping references to Webpack specific build configurations in Readme and adding clarity for CDN/external.
* Fixes #69: Adding capability to reduce production build output size and allow users that import this package to include prop types in development and optionally remove them using Webpacks UglifyJS + Define plugin. * Updated .babelrc that properly wraps prop-types. * Restoring the original constant declaration for prop types as uglify does find dead code and remove it. * Updating changelog.
This is an initial stab at a new api for these components. The goals here are:
Goals:
childFactory
pattern.Transition
componentChanges
Transition
that handles the animation of a single child.TransitionGroup
, deferring a lot of state management toTransition
which are now required as children ofTransitionGroup
CSSTransition
component, which can be used withTransitionGroup
These changes effectively move the transition definitions to the list items instead of list. It's a bit more verbose (easily encapsulated in a component, however), but it provides greater flexibility. For instance you can now easily mix and match transition types for list items, some could Fade, and others slide in. It also provides an opportunity to reuse and share transitions a bit easier. For instance, the react-bootstrap
Fade
component can be implemented in terms of a Transition, and used by itself to animate a single component, or withTransitionGroup
to animate lists of things.Example
with the following css
The removal of the various static method hooks also means it's much easier to encapsulate animations in Components. So we could write the above as
Implications and Concerns
This model complicates concept of
appear
transitions. Since it's theTransition
are always being mounted in aTransitionGroup
as items enter, they are always "appearing". Because the list items are controlling the transition, they don't know whether they are appearing or entering in relation to the parent list. This is somewhat solvable, but a bit ugly. I'd prefer to remove the concept of "appear" from the items in the context of a TransitionGroup, instead maybe just animation the TransitionGroup component itself, for appear animationsNot sure. I'd love some feedback from folks on when and if they use appear animations as separate from the enter animations
I still need to figure out how the API will play with the TransitionGroup component, i do still want the shortcut apis for defining timeouts and enabled/disabled animations in one spot up top.
cc @taion (I moved Transition from react-overlays btw)