"appear" differs from "enter" in that all children of a transition group at mount time will "appear" but will not "enter". All children later added to an existing transition group will "enter" but not "appear".
This extra transition phase allows for animation-on-mount effects.
A mirroring "appear" prop has been added to ReactCSSTransitionGroup, however for reverse-compatibility (and because "appear" is less common) it defaults to false.
Thanks to @afa for his work investigating the possible ways to implement this.
Because the JS community's polyfilling infrastructure sucks and we'll
have to fix it for them before we require this.
JSX spread uses React.__spread
(which might get special behavior for key/ref, not sure yet)
This never uses the native implementation and throws for prototype chains.
Once the native implementations are faster, we'll start using them.
This makes it easier to contribute without having to learn a bunch of
slightly different helpers and remember their slightly different
signatures and semantics.
We'll probably start using ES7 spread properties instead of merge in the
future when at least one more transpiler supports it.
I grepped for uses of React.DOM. This is going to be a set of helper functions
to generate ReactElements without JSX.
They're not classes so they cannot be used where a React class is expected.
Since we always use JSX, we should have no internal use for these helpers.
We can use strings instead.
Replace plain function calls to legacy factories with createFactory or
createElement. For ReactDOMComponents the type should be replaced with
strings.
Because we don't have easy access to ReactLegacyDescriptor from within
React, we need to use the .type property to extract the real class.
This will go away later and is covered by unit tests.
For boolean-like objects, I've added hasOwnProperty checks in addition to the existing truthiness check even though for most of these dicts, we leave out false keys instead of setting them explicitly to false.
In DOMPropertyOperations, we don't need to check hasOwnProperty if the property is in isStandardName because (with the exception of getPossibleStandardName) the dicts on DOMProperty will now be consistently populated with every valid attribute.
With this, multiple setState calls triggered by a componentDidUpdate handler (or similar) will be batched together, regardless of if the original setState call was in a batching context.
I also cleaned up some inconsistencies with the order of component updates and callbacks in situations where one component's update directly causes another to update.
Fixes#1147. Helps with #1353 and #1245 as well, though doesn't completely fix them yet.
Test Plan:
grunt test
Some Android versions have the "transition" and "animation" properties
set on element style objects despite not supporting un-prefxied animations
and transitions. This change adds an additional sanity check to make sure
the correct event handlers are added for transition groups.
Adds a PropType that checks for proper use of the ReactLink API and optionally validates the type of value passed in via the link. Basically, it's a wrapper around PropTypes.shape that hides the implementation of ReactLink.
Looks like while rewriting @petehunt forgot to remove this block.
See: 9ac27cb551
This block used to contain the only `runNextTick` ocurrences in the whole project.
No tests broken after removal, no documentation affected.
This way it doesn't end when some random element elsewhere on the page has an ending transition.
It must be noted that this is not a complete fix. If you have multiple transitions on the element, it still ends when the first ends.
I ran into this not working (the transition ends almost immediately, because some unrelated transition ends). This fixes it for me, but I was wondering whether this cornercase was considered, and whether the other cornercase (multiple transitions) was considered.
I think it's very hard to get this correct, and think it might be better to make the timeout explicit, or at least allow to set it explicit, and fall back to this behaviour. But I'm really interested in feedback on this one.
Dealing with immutable data is hard. This provides a simple helper (ported from the IG codebase) that makes dealing with immutable JSON data easier. Designed to be familiar for people who use MongoDB.
grep -rl 'Copyright 2013 Facebook' static_upstream | xargs perl -pi -w -e s/Copyright 2013 Facebook/Copyright 2013-2014 Facebook/g;'
Not going to check in a script to do this since it will just change every year.
Closes#1006
The key idea here is that you're always rendering `this.state.children`, not
`this.props.children`. When combined with `cloneWithProps()` this means we can
keep them in the DOM as long as we want. We add new children and reactively
update existing ones using `setState()` inside of `componentWillReceiveProps()`
so `this.state.children` always has the latest versions of components. Since we
may be keeping old components around that are no longer in
`this.props.children` we need a way to figure out where they should be inside
of the combined `this.state.children` list. `ReactTransitionChildMapping` does
this for us.
Based on that infrastructure we can build the interface we always wanted: enter
and leave lifecycle hooks.
When a component is added to the DOM, `componentWillEnter(callback)` gets
called. Call the callback when you're done animating and `componentDidEnter()`
will be called.
When a component is about to be removed from the DOM,
`componentWillLeave(callback)` gets called. Call the callback when you're done
animating and `componentDidLeave()` will be called and the component will
*actually* be removed from the DOM. It won't be removed until you call the
callback.
These also handle "concurrent" changes. If you "stack" enter/leaves of a single
component before the animation has completed, it will block out all of those
animations until the current animation completes, and then finally it will
animate 0 or 1 times to get itself into the desired current state. This is what
differentiates `componentWillEnter()` from `componentDidMount()`.
The next step would be to build `componentDidReorder()`.
I've built `ReactCSSTransitionGroup` which is identical to the old
`ReactTransitionGroup` and codemodded the callsites.
Lee Byron
Paul O’Shannessy
Sebastian Markbage
andres suarez
Ben Alpert
Brandon Bloom
Mark IJbema
Marcin Szczepanski
Jonas Gebhardt
Cheng Lou
Irae
plievone
Pete Hunt
Pascal Hartig
petehunt
Andreas Svensson