Summary:
Add explicit annotations to useCallback as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Codemod command: `flow codemod annotate-use-callback`
drop-conflicts
bypass-lint
Changelog: [Internal]
Reviewed By: evanyeung
Differential Revision: D40079418
fbshipit-source-id: 59750a5d07b2ac1f440927794a7523682f048a5e
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
There was a bug on Android when an Animated.ScrollView had a RefreshControl while an Animated style was applied, ie `transform`:
```
<Animated.ScrollView
refreshControl={<RefreshControl />}
style={{
transform: [{
translateY: new Animated.Value(200, {useNativeDriver: true})
}]
}}
/>
```
The transform value was being incorrectly applied twice. Since the styles were applied once on RefreshControl and once on NativeScrollView, the transform style is effectively applied twice:
**1. ScrollView.js**
- RefreshControl gets the transform through Fabric commit
- [The RefreshControl gets wrapped around ScrollView](https://fburl.com/code/k60krxbj) while on iOS there is no change in the parent/child relationship. [Outer/inner styles are split and applied to RefreshControl/ScrollView](https://fburl.com/code/b2to75er), and transform styles are applied on the parent (RefreshControl)
**2. createAnimatedComponent.js**
- NativeScrollView gets the transform through Animated
- [ScrollView forwards its ref to NativeScrollView](https://fburl.com/code/w1whtl5f), which means AnimatedComponent is setting the transform styles on NativeScrollView and not RefreshControl as ScrollView.js did
This diff fixes this bug by using the `useAnimatedProps` hook which makes both RefreshControl and ScrollView components into animated components. Otherwise, the components don't know what to do with Animated values.
---
Changelog:
[Internal][Fixed] - Animated transform style properties were being applied twice when used on an Animated.ScrollView with RefreshControl on Android
Reviewed By: javache
Differential Revision: D38815633
fbshipit-source-id: 2b76639d2237176b6aae4fb1e22cf1a1ec70a69a
Summary:
This PR refactors the Animated directory to use ESModule imports/exports instead of using a mixture of the 2 module formats, as requested on https://github.com/facebook/react-native/issues/34425.
## Changelog
[Internal] [Changed] - Convert all files in the Animated directory to use ESModule imports/exports
Pull Request resolved: https://github.com/facebook/react-native/pull/34539
Test Plan: This doesn't really add or modify any existing features so checking if CI passes should be enough
Reviewed By: yungsters
Differential Revision: D39235720
Pulled By: yungsters
fbshipit-source-id: 84b4c0a71dc9fca1ab7053263f1cf7c336df58c1
Summary:
This replaces all direct references to `ReactNative` within the `react-native` package to use `findNodeHandle` with a reference obtained from `RendererProxy`, which will allow us to select the correct renderer.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39270689
fbshipit-source-id: a39875281ba7b7b1b00128564124b6adcacebc4d
Summary:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
Summary:
Sometime over the past few months (and with changes such as migrating to the `hermes-eslint` parser), a bunch of lint warnings crept into the codebase.
This does a pass to clean them all up, ignore generated files, and refactor some code to be... better.
There should be no observable behavior changes as a result of this.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646643
fbshipit-source-id: a7b55d1e4cd5700340cc5c21f928baf3ea1d5a58
Summary:
Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent.
1) Run my one-off jscodeshift codemod
2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change)
drop-conflicts
Reviewed By: bradzacher
Differential Revision: D37834078
fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581
Summary:
Ahead of enabling the `exact_empty_objects` option, suppress errors so that actually enabling the option is easier. We can do this without enabling the option by codemoding `{}` to `{...null}` in files that have errors.
Process:
1) Get list of files with errors when enabling the option
2) Codemod `{}` to `{...null}` in those files
3) Suppress resulting errors
4) Land diff with `drop-conflicts` flag
5) Announce and enable option (with many fewer files to edit)
6) Codemod all `{...null}` to `{}`
drop-conflicts
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
More info in these posts: https://fb.workplace.com/groups/flowlang/posts/903386663600331, https://fb.workplace.com/groups/floweng/posts/8626146484100557
Reviewed By: pieterv
Differential Revision: D37731004
fbshipit-source-id: a9305859ba4e8adbdb8ae8feff3ec8a2f07ed236
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: bradzacher
Differential Revision: D37363351
fbshipit-source-id: a9d3df7db6f9d094ac2ce81aae1f3ab4f62b243a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) changed Animated to only use value of natively driven nodes on initial render.
However, there remained a case where we could end up with a race condition between Fabric prop update (via SurfaceMountingManager.updateProps) and Animated (via NativeAnimatedNodesManager.runUpdates), when an animation on a node that was created natively is triggered close to render (such as in componentDidUpdate). This happens as Animated and Fabric aren't synchronized, and at the platform level, they do not know each other's state.
Say we have two items, where opacity is used to indicate whether the item is selected. On initial render, A's opacity is set to 1, and animated sets opacity to 1; B's opacity is set to 0, and animated sets opacity to 0. When B is selected (and causes A and B to rerender), A's opacity is now set to null, and animated sets opacity to 0; B's opacity is also now set to null, and animated sets opacity to 1. A's props have changed, and thus the default opacity value of 1 is applied via Fabric, but Animated also sets the opacity to 0 - either may end up being the value visible to the user due to the nondeterministic order of Fabric update props and Animated. This is what is causing T122469354.
This diff addresses this edge case by using the initial prop values for native animated nodes, for subsequent renders, to ensure that values of native animated nodes do not impact rerenders.
This diff also fixes a bug in OCAnimation where translateX/Y values of 0 in transition will result in render props containing translateX/Y instead of transform, resulting in potentially incorrect pressability bounds.
Changelog:
[Internal][Fixed] - Only use initial value of natively driven nodes on render
Reviewed By: JoshuaGross, javache
Differential Revision: D36958882
fbshipit-source-id: 10be2ad91b645fa4b8a4a12808e9299da33aaf7d
Summary:
D36612758 (https://github.com/facebook/react-native/commit/40f4c662bc7a66e5caea4909d74f435f5b72190c) attempted to remove the check that the animated node was native when fetching animated prop values for render, in order to fix an issue that arises when a node is converted to native before the initial call to render to mount the component, where the initial value is not applied.
However, this causes issues for cases where we call setValue on an animated node soon after render, such as on componentDidUpdate. setValue first updates the animated node value on JS side, then calls the native API setAnimatedNodeValue. The problem is that the next render will then use these updated values in the style props (because we removed the check for native in D36612758 (https://github.com/facebook/react-native/commit/40f4c662bc7a66e5caea4909d74f435f5b72190c)), resulting in a diff in props. Since Animated and Fabric aren't synchronized, there's a race condition between SurfaceMountingManager.updateProps and NativeAnimatedNodesManager.runUpdates
To allow proper rendering of initial values of native animated nodes, and mitigate the issue when calling setValue on an animated node soon after render, during initial render we use the initial values of both native and non-native driven nodes, and on subsequent renders we only use the initial values of non-native driven nodes.
An alternative considered was to add internal state to the nodes themselves (AnimatedProps, AnimatedStyle), but keeping it in sync with the component state is not easy/clean as AnimatedProps can be recreated and reattached at any time for a mounted component.
Changelog:
[Internal][Fixed] - Only use value of natively driven nodes on initial render
Reviewed By: JoshuaGross
Differential Revision: D36902220
fbshipit-source-id: c20f711aa97d18a2ed549b5f90c6296bf19bb327
Summary:
This diff upgrades xplat to 0.178.1 and pre-suppresses errors from turning on constrained writes.
To generate this diff I:
* Modified every `env_mode=constrain_writes` to `env_mode=ssa` and made a commit (this is so our upgrade script will work)
* Ran scripts/flow/upgrade.sh 0.178.1 to upgrade all the flowconfigs to 178.1 and suppress new-env errors
* Modified arvr/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project arvr`
* Modified xplat/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project xplat`
* Unstacked from the commit in point 1
Reviewed By: SamChou19815
Differential Revision: D36676019
fbshipit-source-id: c3032f18ed838afc327f00de563e7f20713bdc26
Summary:
In AnimatedComponent.render, we get the initial values of any styles backed by AnimatedNode, but ONLY for non-native animations. Thus, if convert an animated node to native before the call to render to mount the component, we will end up not applying the initial value until after the component is mounted. This may result in a visible flicker as the expected value is applied some time after the component is mounted and visible.
- Without native driver: BaseViewManager.setTransform called during view preallocation (ViewManager.createViewInstance)
- With native driver: BaseViewManager.setTransform called during MountingManager.updateProps (called from PropsAnimatedNode.updateView)
This diff removes the isNative check in AnimatedStyle and AnimatedProps when traversing style props. This shouldn't be a problem:
- Created as non-native, animated with JS driver
- This diff does not affect this scenario
- Created as non-native, animated with native driver
- Initial value is applied correctly on render/mount. On subsequent renders, the outdated value from JS side will not apply on the platform view as it has not changed.
- Created as native, animated with native driver
- Initial value is applied correctly on render/mount. On subsequent renders, the outdated value from JS side will not apply on the platform view as it has not changed.
Changelog:
[Internal][Fixed] - Set correct initial value for AnimatedComponent for styles backed by native animated nodes
Reviewed By: JoshuaGross, javache
Differential Revision: D36612758
fbshipit-source-id: 922d6534c605b3eb0a1d9476753111b726f138f2
Summary:
setImmediate will result in these debounced/queued operations being sent to native immediately at the end of a ReactJS render loop instead of in the next tick, which could result in more fluid animations.
I verified with logs that batching still occurs.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36521717
fbshipit-source-id: 4f94e26503d4e6e40f52a4120ae407044af0c451
Summary:
Call `setWaitingForIdentifier` before we do any `setValue` calls to make sure we execute them together (and only call start/finish batch once). Only calll `updateAnimatedNodeConfig` conditionally when we changed nativeColor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36517302
fbshipit-source-id: ecbae2d1df69e4456620c58a922275406e22a2f8
Summary:
Splitting these changes of from D36482630, which is a minor improvement to the singleOp experiment. Since we call start/finish already on the native side, we don't need to repeat it from JS.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36541700
fbshipit-source-id: 7d61669710faca3153be557fb2d214011eda87c5
Summary:
There are use cases of needing to setValue multiple times per second (for example, using PanResponder to update a slider component).
This requires the use of the native driver for perf reasons as using the JS driver will cause a rerender. Currently, the only way to make an animated node native is via setting useNativeDriver: true on an animation config. For example:
```
Animated.timing(animatedValue,
{
toValue: newValue,
duration: 0,
useNativeDriver: true
}).start();
```
To avoid needing to call the above, add a useNativeDriver param to the constructor. When set to true, the node will be made native immediately.
```
const animatedValue = new Animated.Value(0, useNativeDriver);
...
animatedValue.setValue(newValue);
```
Note that, like with useNativeDriver in the animation config, once a node is made native, it cannot be reverted to JS-only.
---
As an aside, PanResponder uses JS-side events, and thus we cannot use Animated.event with native driver; we instead need to setValue on a native AnimatedValue. A much more thorough explanation is in D34564598.
---
Changelog:
[General][Added] - [Animated] Add useNativeDriver as a param for setValue
Reviewed By: JoshuaGross
Differential Revision: D36459457
fbshipit-source-id: 284148a6d16537429efeab8b07184019990909cd
Summary:
Improve the types of `queueOperation` so flow can assert that the parameters match.
Also in the case of `singleOpBatching == false`, nativeOps is just an alias of NativeModule so there's no overhead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36482617
fbshipit-source-id: e000d11b04166cd7a069af024b9c2cc226efa701
Summary:
We introduce a few optimizations:
(1) Previous diff: We defer calling any NativeAnimatedModule methods by waiting 1ms before flushing the queue, and debouncing until no flush is requested. Practically, this just means that we'll call NativeAnimatedModule methods N times at once, at the end of a render loop, instead of N times smeared throughout the render loop.
(2) Additionally, instead of calling N methods, we create multi-operation argument buffer and call a single NativeAnimatedModule API, which should essentially throttle NativeAnimatedModule API calls to once-ish per frame. On the native side, this also reduces a lot of overhead associated with scheduling work on the UI thread (we schedule 1 function to run on the UI thread and perform N operations, as opposed to scheduling N functions to run on the UI thread).
TODO:
- implement stubs for iOS
- write gating code so this can be properly tested in VR and in fb4a
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338606
fbshipit-source-id: 29ac949b53b874683128a76525586c22def3143b
Summary:
Because of the disconnect between the ReactJS render loop and Animated nodes, we don't know when a render loop begins or ends. Historically we haven't cared about that much,
but now for perf reasons we're attempting to batch them. Scheduling a function to execute at the end of the runloop and canceling until nothing interrupts it achieves that.
Impact seems fairly minimal and this should work everywhere (android, ios, etc) but we may want to gate the behavior as it *could* change things in surprising ways.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338621
fbshipit-source-id: 48e52a1b2e2bcfb3ef13d3abd38d735967356de7
Summary:
This patches a loophole in the logic that caused some operations to execute immediately and some to be deferred, even within the same render loop. This caused the non-queued operations to be executed out of order. Instead, if an operation is created and a queued exists, we just push the operation to the end of the queue so ordering is preserved.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36379125
fbshipit-source-id: d9f63f4d47d8453d51add61763b7b9c74ffe9d88
Summary:
Small win: if the queue is empty we shouldn't start/stop the batch.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36298399
fbshipit-source-id: b43c07994ba28b4c890fe52af4e81c265a3b8ac7
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Some manual fixes, in particular to React Native code, which is used and can be synced to other repos (e.g. WWW).
With these changes, error diff in Xplat is down to ~1990 errors
Note that after I roll out `exact_empty_objects`, I'll codemod all the `{...null}` (the only way to get an exact empty object currently) back to `{}`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D36142838
fbshipit-source-id: 054caf370db230f42a4c5f5706c88979ef246537
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Making this change exposes a variety of errors. We can prevent these errors by annotating what we want the type of the empty object to be.
Reduces Xplat error diff to 2.3k
- Announcement: [post](https://fb.workplace.com/groups/flowlang/posts/903386663600331)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
Format:
```
arc f
```
Sort imports
```
hg l -n | xargs js1 lint --fix --rule 'fb-tools/sort-requires'
```
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D36086696
fbshipit-source-id: 90447279f2e6e38f44189b74ec0297719f7adf58
Summary:
Changelog:
[General][Fixed] - Improved Flow type inference in Animated `.interpolate()`
Improves the ergonomics of `.interpolate()` by allowing Flow to infer the correct type for `outputRange`. This is achieved by adding a new type parameter `OutputT` to `interpolate()` (and `Animated.Interpolation` and `InterpolationConfigType`), which Flow infers as either `number` or `string` based on usage.
Admittedly, at the call site, this is not that much safer compared to something like `outputRange: $ReadOnlyArray<number | string>`, but it does document the intent of the API a bit better and provide some downstream type safety. For example, we can now express `Animated.Number` (D35869375) more precisely by excluding string-valued interpolation nodes.
Reviewed By: javache
Differential Revision: D35869725
fbshipit-source-id: e03ec22e9b3368ee196b392af011062ac99d8bb9
Summary:
Changelog: [General][Added] - Add `Animated.Numeric` Flow type
Adds a Flow type to represent the various Animated node types that evaluate to numeric values and can be `interpolate()`d.
I'm including `AnimatedInterpolation` as "numeric" here even though it can technically evaluate either to a number or to a string, depending on its config. Note that calling `interpolate()` on a string-valued `AnimatedInterpolation` is a runtime error.
In a future diff, I'm planning to add a type argument to `AnimatedInterpolation` (and its config type), at which point we can refine `Animated.Numeric` to correctly include only `AnimatedInterpolation<number>`.
Reviewed By: javache
Differential Revision: D35869375
fbshipit-source-id: 2ff6754f1a5abc68c9da2c6836872c2022b25676
Summary:
This drastically improves `Animated.interpolate` performance when `inputRange` has a considerable amount of elements (~100 in my tests).
For instance in `ActivityIndicator` inside `react-native-paper`, the input has 144 elements https://github.com/callstack/react-native-paper/blob/main/src/components/ActivityIndicator.tsx#L170. `react-native-elements` has 9k stars, so I'm assuming this is widely used.
### Cause
The reason for the performance drop is that if we assume `n` to be the size of the range, calculating `'inputRange must be monotonically non-decreasing ' + arr` essentially calculates `arr.toString()` which has O(n) complexity.
Since it is recalculated in a for loop, we end up with `checkValidInputRange` having a O(n²) complexity. Which means ~10k operations if the array has a size close to 100.
## Changelog
[General] [Fixed] - Fix performance issue on Animated.interpolate with big input range
Pull Request resolved: https://github.com/facebook/react-native/pull/33598
Test Plan:
[Here's a repo](https://github.com/Almouro/AnimatedInterpolationRepro) reproducing the issue.
The branch `fix` includes the fix.
Clicking `Interpolate` runs:
```js
new Animated.Value(0).interpolate({
inputRange: Array(144)
.fill()
.map((_, i) => 1 / (i + 1))
.reverse(),
outputRange: Array(144)
.fill()
.map((_, i) => 1 / (i + 1))
```
Here's a comparison of JS thread perf before the fix and after the fix:
- on a Samsung J3 2017 (lower end)
- using Flipper and https://github.com/bamlab/react-native-performance)
- ` __DEV__` mode deactivated
- clicking the button and waiting 15s
| Before | After |
|----------|:-------------:|
|  | |
The error still throws if `inputRange` is incorrect:
<img width="517" alt="image" src="https://user-images.githubusercontent.com/4534323/162439219-6ce120ae-98e5-496b-899a-492978689d6d.png">
However if `__DEV__` mode is deactivated, no error is thrown
Reviewed By: yungsters
Differential Revision: D35507441
Pulled By: javache
fbshipit-source-id: 36ac49422f7a42d247130c42d12248b2be1232c6
Summary:
Before, when we called setValue with a PlatformColor, we unnecessarily called setValue on all component AnimatedValues before updateAnimatedNodeConfig.
This diff also fixes a bug where if we set a PlatformColor as the initial color, calling setValue with a non-PlatformColor would not have any effect. The fix is to reset AnimatedColor.nativeColor to null upon calling setValue.
Changelog:
[Internal] Optimize AnimatedColor when setting platform color
Reviewed By: javache
Differential Revision: D34187540
fbshipit-source-id: a0005d13f392a858d2eade912f2353f67eec1fd9
Summary:
Now that animating color styles using native driver is supported on both Android and iOS, add color styles to the allowlist in NativeAnimatedHelper.
Changelog:
[General][Added] - Allow color styles to be animated using native driver
Reviewed By: mdvacca
Differential Revision: D34148038
fbshipit-source-id: c20dc149b805ec691a3936a77ab130fb4477a4c3
Summary:
In order to support AnimatedColor.setValue for platform colors, we need to pass the platform color object to the native animated node which will then resolve and apply the color.
Thus, the approach is:
- Add a new API updateAnimatedNodeConfig to NativeAnimatedModule
- [JS] On AnimatedColor.setValue, if the value is a platform color, then we call updateAnimatedNodeConfig
- [Android] We introduce AnimatedNodeWithUpdateableConfig interface with a method updateConfig. On ColorAnimatedNode.java, we use updateConfig to resolve and apply the color
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color
Reviewed By: javache, mdvacca
Differential Revision: D34025193
fbshipit-source-id: 8b368f6b7cb2cf7cebe8b66461cd4185cbadd44c
Summary:
Changelog:
[General] [Changed] Type the argument of Animated.interpolate as read-only
Reviewed By: javache
Differential Revision: D33950698
fbshipit-source-id: b959d34eb9752358f4a8ba1d290b56c099f535e0
Summary:
The JS-side animated node values were not being updated on AnimatedValue (and thus AnimatedValueXY); however, the native event "onAnimatedValueUpdate" is being handled properly in AnimatedNode. It turns out that single underscore prefixed methods are obfuscated at FB. And thus AnimatedValue._onAnimatedValueUpdateReceived was not getting called. Changing the method name to double underscore as a way to denote "protected" fixes the issue.
Changelog:
[General][Fixed] - JS animated node value updates properly when listener is attached
Reviewed By: yungsters
Differential Revision: D33962038
fbshipit-source-id: c4f60e1f1ccc0cef3e65b89034bdb91376a26416
Summary:
Adds support for platform colors in AnimatedColor.
Passes the processed native color object to the native ColorAnimatedNode via the native config; ColorAnimatedNode then uses ColorPropConverter.getColor to resolve the resource path.
Note: setting a platform color via setValue on an existing AnimatedColor is not supported yet
Changelog:
[Android][Added] - Support platform color with AnimatedColor
Reviewed By: yungsters
Differential Revision: D33922266
fbshipit-source-id: 04d39a5ce0872b31d06ffbd4639d2f2213cf3314
Summary:
Adds support for Animated.Color with native driver for Android. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into an integer (0xaarrggbb)
Followup changes will include support for iOS and platform colors.
Changelog:
[Android][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: javache
Differential Revision: D33833600
fbshipit-source-id: 2bf05c9715b603cf014ace09e9308b2bfd67f30a
Summary:
In addition to rgba values, allow creating Animated.Color with a string color.
Followup changes will include support for platform colors and native driver.
Changelog:
[General][Added] - Support string color values in Animated.Color
Reviewed By: javache
Differential Revision: D33810717
fbshipit-source-id: 208bc2675b6153a515fbf2122da15a065c473e73
Summary:
Creates Animated.Color for animating color props.
Implement AnimatedColor, which basically consists of 4 AnimatedValues (along the same vein as ValueXY) which allows us to just use AnimatedValue's interpolation. Provides a string color value of shape 'rgba(r, g, b, a)'
AnimationNode DAG looks like:
{F696076974}
Followup changes will include support for string color values, platform colors, and native driver.
Changelog:
[General][Added] - New Animated.Color node
Reviewed By: mdvacca
Differential Revision: D33778456
fbshipit-source-id: 83ddbc955156bf589c864f229a5f83fe6875fd0e
Summary:
In Animated, when a toValue of AnimatedValue (as opposed to a number) is passed in, the [AnimatedValue starts tracking via AnimatedTracking](https://www.internalfb.com/code/fbsource/[b688f3747a706236fce300636978ed1ca5e4081a]/xplat/js/react-native-github/Libraries/Animated/AnimatedImplementation.js?lines=142) but it doesn't actually start animating even if start() is called on the animation.
This behavior is inconsistent with a toValue of a number, which executes immediately on start(). This diff adds a call to AnimatedTracking.update within AnimatedValue.track, which starts the tracking animation.
Changelog:
[General][Fixed] - Fixes execution of animation when a toValue of AnimatedValue is used.
Reviewed By: JoshuaGross
Differential Revision: D33800373
fbshipit-source-id: 85ee6f51bc2bb2e078b586b076a8d1dfe92c1155
Sam Zhou
Tim Yung
Nick Gerleman
Sharon Zheng
Gabriel Donadel Dall'Agnol
Rujin Cao
Rubén Norte
Pieter Vanderwerff
Samuel Susla
Tim Yung
George Zahariev
Genki Kondo
Jordan Brown
Eric Hartzog
Joshua Gross
Pieter De Baets
Moti Zilberman
almouro
