Skip to content
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

v9.0.0-rc.1 #978

Merged
merged 751 commits into from
May 3, 2020
Merged

v9.0.0-rc.1 #978

merged 751 commits into from
May 3, 2020

Conversation

aleclarson
Copy link
Contributor

@aleclarson aleclarson commented May 3, 2020

The native target had the least broken AnimatedLeaf type (from earlier commits).

This makes "AnimatedProp<string | string[] | undefined>" resolve to

    string | string[] | FluidValue<string | string[]> | undefined

instead of

    string | FluidValue<string | undefined> | (string | FluidValue<string>)[] | undefined
Complain via TS error when the "to" prop has a FluidValue type whose "T" param extends "void".
This variable decides if a SpringValue needs to be in the frameloop. Previously, it was using "value" (the current value) before the "reset" and "from" props were applied.
The "reverse" prop only affects a single update
It wasn't working for tests in "packages/core" :(
The implications of this commit are subtle.

- The internal Animated node is now replaced (1) when the "set" method is passed a different value type and (2) when the "from" value type is changed before ever animating.

- Before ever animating, the Animated node has its value updated to the newest "from" value.

- Stop passing the "from" value to "computeGoal" when creating the Animated node.

- Account for the "reverse" and "delay" props when deciding what the "from" value is.
The only non-animated value type that's allowed in a SpringValue object is a string, and the "goal" local var will only be a string when it cannot be animated.
By default, it advances one frame, but that can be controlled.
- Ensure active animations cannot be interrupted by "to" prop changing to current value
- Prevent pending animations when "to" prop changes to current value
This should fix #887, because changing of the "config.decay" prop now affects the "started" variable.

Also, a new variable named "finished" detects if the current value equals the latest goal value.
The "props function" overload must come first, or else the other overloads will be used.
@aleclarson aleclarson changed the base branch from master to v9 May 3, 2020 19:31
@aleclarson aleclarson mentioned this pull request May 3, 2020
8 tasks
T825084@spark.co.nz and others added 2 commits May 3, 2020 17:00
@aleclarson aleclarson merged commit cedeed0 into v9 May 3, 2020
@aleclarson aleclarson deleted the v9-rc.1 branch May 3, 2020 21:02
@phaistonian
Copy link

Whoa :)

When is this coming to npm?

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