Releases: joshwcomeau/react-flip-move
v1.0.4
Fix issue with children removed from the DOM
In the last patch, I improved filtering to check whether DOM nodes had moved, before moving on to the 'animation' step. This had the inadvertent effect of always trying to get the bounding rects for all DOM nodes in the previous state.
An exception was being thrown when DOM nodes were destroyed, because it was trying to calculate the bounding rects for elements that no longer exist.
Simple fix, by returning earlier if the DOM node is destroyed, new, or immovable (no child key).
NOTE: This release, due to a mistake I made assuming NPM modules could be unpublished/republished, comprises both v1.0.3 and v1.0.4
v1.0.2
Fix whichTransitionEvent server crash
I had borrowed a helper method from Modernizr to check which transitionend event to listen to (most browsers support the base transitionend, but legacy browsers need vendor prefixes).
This method works by creating a DOM node and evaluating which style property it has.
When using React SSR, though, no DOM exists, so the call to document.createElement was throwing an exception.
Fixed the problem by returning an empty string if no DOM is detected.
v1.0.1
Update README
World's smallest version bump.
- Added a Gotcha to the README about not using stateless functional components with FlipMove
- Removed some links from the options table in an attempt to fix how weirdly it's formatted on NPM. Didn't work =(
v1.0.0
Initial Release
Went through and sanded all the little edges that had been bothering me. Flip Move is ready for primetime :)
v0.2.3
Proper filtering of children
Previously, not all children were being filtered out before the primary animation iteration.
While in that iteration, I was still returning early if the children didn't need to be animated, it was messing with staggerDurationBy and staggerDelayBy.
For example, let's say we have a Flip Move with 6 children and a staggerDelayBy of 20ms.
We move only the last item. Because there is only 1 item being animated, it should start transitioning immediately.
In the previous version, the element would not start transitioning until 100ms later; it was the 6th child in the sequence and even though none of the others were moving, we were still waiting for them.
Fixed now =)
v0.2.2
Add prepublish NPM task
To ensure that NPM receives the most up-to-date lib and dist, I added a task to NPM to build both regular and UMD builds before publishing.
v0.2.1
Fix UMD bundle
Small fix to ensure the UMD bundle doesn't include React, and the min/unmin files are correct.
Got the .min down to just 5kb, which drops to a microscopic 2073 bytes when gzipped :D
v0.2.0
Ditched Google's Web Animations API
It turns out that while the Web Animations API is super neat, it introduces problems in certain browsers when combined with React lifecycle methods. The native Javascript method requestAnimationFrame does everything I need with comparatively fewer headaches. Fixes #2
Animations can now be interrupted without flickering!
Previously, when you triggered a new animation before the current one was complete, the element would jump to its final position and start from there. Now, the element will move to its new course smoothly.
New property staggerDelayBy
Similar to staggerDurationBy, this property adds a delay to each subsequent element before the animation starts.
v0.1.7
Add onStart / onFinish callbacks
Converted the previous onComplete callback to onFinish, for parity with the Web Animations API player event. Also refactored it so that it doesn't clobber a bound context, if context is needed for the callback.
Added an onStart callback to run at the start of the animation, once per element.
Both callbacks are supplied two arguments: The React Element they're operating on, and the unwrapped DOM node (which shouldn't be needed in most cases, but it's an escape hatch).