Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
Summary:
This PR was created in response to feedback from an older PR: https://github.com/facebook/react-native/pull/2045
The `.interpolate()` API of Animated values is quite effective to accomplish transformations based on a single animated value, but currently there is a class of animations that is impossible: animations being driven by more than one value.
Usage would be like the following:
```js
getInitialState: function() {
return {
panY: new Animated.Value(0),
offset: new Animated.Value(0),
};
}
```
```js
var scale = Animated.add(panY, offset).interpolate({
inputRange: [...],
outputRange: [...],
});
```
I have a real use case for this, and I cannot think of any way to accomplish what I need without an API like this.
The animation I am trying to accomplish is I have a PanResponder being used to detect both x and y panning. The y-axis panning drives a 3d sroll-like animation (which we can call `panY`), and the x-axis panning is driving a "swipe-to-remove" animation (
Closes https://github.com/facebook/react-native/pull/4395
Reviewed By: svcscm
Differential Revision: D2731305
Pulled By: vjeux
fb-gh-sync-id: 3b9422f10c7e7f3b3ecd270aeed8ea92315a89e9
Summary:
public
This causes a warning since propType not exist
Reviewed By: vjeux
Differential Revision: D2713358
fb-gh-sync-id: 58406d1dc969e6f1d40bee958c28cc87036b30c2
Summary: Adds a new option to animation configs so that animations can be marked as non-interactions. This solves the "loading indicator problem" where an animated loading screen would deadlock as it waits for all interactions to complete.
As for the API, what we really want long term is better scheduling. This needs to be built at the runtime level (into the RN bridge) and take care of things like priority donation that are probably overkill right now. Basically this API is a medium-term fix and I won't be upset if it gets replaced with a finer-grained scheduler.
Closes https://github.com/facebook/react-native/pull/3433
Reviewed By: @svcscm
Differential Revision: D2545300
Pulled By: @vjeux
fb-gh-sync-id: c1216bf69bfbbbae00c76c4697183fe96a6a01dd
Summary: These were accidentally supported because they were merged at a lower
level. That's an implementation detail. setNativeProps should still
normalize the API.
I fixed some callers.
Setting props the normal way used to ignore these. Unfortunately we can't
warn for those cases because lots of extra props are spread. (The classic
transferPropsTo issue.)
@public
Reviewed By: @vjeux
Differential Revision: D2514228
fb-gh-sync-id: 00ed6073827dc1924da20f3d80cbdf68d8a8a8fc
Summary: 1. Should I add an example of this to the UIExplorer Animation example?
2. Should I support mixing hex and rgba values in outputRange? It is possible with this implementation, but may cause confusion
Closes https://github.com/facebook/react-native/pull/3177
Reviewed By: @svcscm
Differential Revision: D2506947
Pulled By: @vjeux
Summary: @public
This diff does a couple of things:
- Move all the code in a src/ folder
- Move bezier.js in the Animated folder
- Rename Animated.js into AnimatedImplementation.js and adds two entry points: AnimatedReactNative.js and AnimatedWeb.js
- Implement very dumb polyfills for flattenStyle, Set and InteractionManager
- Import my work in progress demo.html file to make sure that the code is actually working.
Everything is not working correctly:
- It calls forceUpdate on every frame and doesn't use bindings because setNativeProps is not implemented
- None of the style: {transform} are working because React web doesn't know about the array notation for transform
- The demo need more work
Reviewed By: @sahrens
Differential Revision: D2464277
Summary: @public
Make the flow type of TimingAnimationConfig and TimingAnimation the same as SpringAnimationConfig and SpringAnimation.
This is a more accurate flow type as both are multiplexed through maybeVectorAnim().
Reviewed By: @sahrens
Differential Revision: D2410166
Summary:
1) Makes params more intuitive (only one now, bounciness, which maps intuitively to number of oscillations).
2) Satisfies boundary conditions (f(0) = 0, f(1) = 1) so animation actually goes where you tell it (before it would finish at a random location depending on the input params).
3) Simple test to verify boundary conditions.