Skip to content

Conversation

Nizarius
Copy link
Contributor

@Nizarius Nizarius commented Apr 15, 2019

Following my comments on #621.

This small fix makes useTransition work as expected:
if we don't update items props, it shouldn't call update.

Indispensable fix for functional components that have more than one prop. At the same time, the solution might not be the best one so wait your comments.

aleclarson and others added 19 commits April 12, 2019 17:00
The "config" prop of useSpring is used as the default "config" of any async updates which have no explicit "config"
The `_stopAnimation` method is called whenever a new key is animated, which updates the `timestamps` map.

There was a race condition where the `now()` function could return a number that was 1ms greater than the timestamp used for the entire `update` call.
In addition to "config", now the "immediate", "reset", and "reverse" props only apply for one update.

Also, the "immediate" prop of useSpring is used as the default when an update has no explicit "immediate" prop.
A prop should be updated if the timestamps are equal.
Not just "string" or "number"
The "to" and "from" props are now swapped before diffing.

This means `this.props` will always be up-to-date.
It is very important to call `setValue(fromValue)` before `reset(isActive)`, because the `reset` method sets the `startPosition` and `lastPosition` properties to the current `value`.
Never return null. Stop warning about non-animatable values, since they are perfectly legal.
The "attach" prop must be false when no controller should be attached to.

Instead, it was undefined, so it was ignored by the diffing algorithm. This meant that when `reverse` turned false from true, the last controller stayed attached to the 2nd-to-last controller when it should have been the "leader of the pack".
@Nizarius
Copy link
Contributor Author

Nizarius commented Apr 17, 2019

Please, give me some feedback. I also want to add extraKeys as described:
#621 (comment)

But I need to know that this conception is OK. At least, in my project it is a silver bullet and, I suppose, many developers would like to have such an ability from the box.

@aleclarson
Copy link
Contributor

So basically, users would memoize the items argument to prevent update animations?

I think memoizing the update object might be better. WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants