Update react-motion from 0.1.0 to 0.5.1 #1924
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
react-motion has been updated to 0.5.1 by dependencies.io
0.5.1
0.5.0
Breaking
^0.14.9 || ^15.3.0Changes
prop-typespackagePRs:
0.4.8
0.4.7
didLeaveforTransitionMotion! Please check the README for more.0.4.6
No content found.
0.4.5
No content found.
0.4.4
0.4.3
TransitionMotionstylesfunction not being passeddefaultStylesvalue upon first call. Add base html tag to the iframe when building #296onRestcallback forMotion!0.4.2
TransitionMotionkeys merging bug. new proxy: propsInfo #264TransitionMotionrare stale read bug. chenglou/react-motion@f20dc1b0.4.1
0.4.0
springhelper's format has changed fromspring(10, [120, 12])tospring(10, {stiffness: 120, damping: 12}).style,stylesandstylesof the three respective components now only accept either a number to interpolate, or aspringconfiguration to interpolate. Previously, it accepted (and ignored) random key/value pairs mixed in, such as{x: spring(0), y: 'helloWorld'}.yDoesn't belong there and should be placed elsewhere, e.g. directly on the (actual react) style of the component you're assigning the interpolating values on.TransitionMotiongot an all-around clearer API. See the upgrade guide and README section for more.Motion's'defaultStyle, informally accepted the format{x: spring(0)}. This is now officially unsupported. The correct format has always been{x: 0}. Setting a default style of{x: spring(whatever)}did not make sense; the configuration only applies for astyle, aka destination value. Same modification applies toStaggeredMotionandTransitionMotion'sdefaultStyles&willEnter.TransitionMotion'swillEnter/willLeave's signature has changed.reorderKeyshelper is no longer needed thanks to the changes toTransitionMotion. It's now removed.springhas acquired a new field as part of the new signature: precision tuning!0.3.1
nullandundefinedinstyle/styles. Conflicts with NPM Shrinkwrap #181src/folder is now exposed on npm so that you can take advantage of Flow by using:import {Motion} from 'react-motion/src/react-motion'directly, instead of the old, prebuiltimport {Motion} from 'react-motion'. This is experimental and intentionally undocumented. You'll have to adjust your webpack/browserify configurations to require these original source files correctly. No harm trying of course. It's just some type annotations =).0.3.0
0.2.7
0.2.6
require('react-motion/native').0.2.5
No content found.
0.2.4
nullfrom children function. Fix the prepublish script #101defaultValuefor specifying a... default value, upon mounting.TransitionSpring'swillLeaveAPI got simplified and now asks for an object as a return value instead ofnull.nullis still supported, but is deprecated and will be removed in the next version. See the new docs on it here.presets.0.2.3
No content found.
0.2.2
0.2.1
No content found.
0.2.0
willLeavereturningfalsewill now keep the key. Onlynullandundefinedwill serve as a signal to kill the disappeared key.willLeavepreviously failed to expose the second argumentcorrespondingValueOfKeyThatJustLeft. It's now exposed correctly.willLeaveis now called only once per disappearing key. It was called more than once previously as a implementation detail. Though you should never have put side-effects inwillLeave. It's still discouraged now.this.props.handlerThatSetStateAndUnmountsSpringInOwnerRender()inSpring'sendValue, Spring's already scheduledrequestAnimationFramewill no longer cause an extrasetStatesince it's unmounted. But in general, please don't put side-effect inendValue.requestAnimationFrame). Atom plugin #57requestAnimationFramepolyfill.