Summary:
Accidentally added a reference to a flow type that doesn't exist in TS. This should fix the issue.
Changelog:
[General][Fixed] - Fix missing animation type
Reviewed By: christophpurrer
Differential Revision: D42043293
fbshipit-source-id: 03470aa25f503337e9e2b79cf74cff96c15a4ad8
Summary:
When using the `g` modifier on the regex, match and matchAll's behaviour is equivalent, and match has better backwards compatibility on older iOS versions.
Changelog: [General][Fixed] Fixed a backwards compatibility issue with AnimatedInterpolation
Reviewed By: yungsters
Differential Revision: D41879036
fbshipit-source-id: 240dda85ef0de8e27452846c77114ac46823f74f
Summary:
Color support for AnimatedInterpolation was incomplete with native drivers, as only rgba type strings were supported. There was also an issue where color props instead a StyleAnimatedNode would never get applied. We were also potentially duplicating color parsing support, which is already centralized in `normalizeColor` / `processColor`.
Changelog: [Android][Added] Enable AnimatedInterpolation to interpolate arbitrary color types.
Reviewed By: mdvacca
Differential Revision: D40571873
fbshipit-source-id: 41857ab0391279c5307bc31b855ea8fbcb4cccd8
Summary:
Restructured the JS implementation of AnimatedInterpolation to make it clearer how colors and other string-based interpolatables are supported. We're then able to use a very similar structure to implement this interpolation on the native driver as well, which simplifies implementation, and improves support for different color types.
Changelog: [General][Fixed] Improved support for AnimatedInterpolation of color props.
Reviewed By: mdvacca
Differential Revision: D40571890
fbshipit-source-id: 7c204a7b736722732dc5f9e0d158ef5af81b4bb1
Summary:
Animated.Color was never calling `flush`, and thus didn't trigger any animated views to update when the Animated.Color had (a native-only) color change when using the JS driver.
Changelog: [General][Fixed] Improved handling of native colors in Animated.Colors
Reviewed By: mdvacca
Differential Revision: D41519965
fbshipit-source-id: 52f78460cf67ab9260d3868b0d27692b64fc3c58
Summary:
Inlines `setAndForwardRef` into `createAnimatedComponent.js`.
I am planning to delete `setAndForwardRef` because it encourages a subtle bad practice with management of the referential equality of `ref` entities. I am doing this instead of refactoring `createAnimatedComponent` because this legacy implementation is planned to be replaced very soon.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41205066
fbshipit-source-id: dc481e73a6c4d6acbae530d4da48b3a032575179
Summary:
changelog: [internal]
Call `AnimatedProps.setNativeView` any time `AnimatedProps` node changes to make sure it is always connected to underlaying host component.
Reviewed By: yungsters
Differential Revision: D41122065
fbshipit-source-id: 1d10fdd44933ff82d9bfc424cecb2640b7a66837
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
Summary:
Changelog:
[General][Added] - Introduce `useAnimatedValue` hook to make it easier working with `Animated.Value`s in function components.
Reviewed By: javache
Differential Revision: D40434219
fbshipit-source-id: 3caf6ad98d11a534b8cc6816820bc1d125150380
Summary:
changelog: [internal]
Removing listener on detached node leads to a red box, if the said node is `DiffClampAnimatedNode`. This is because calling `AnimatedNode.__getNativeTag()` makes native module call and creates node in native. This node is not completely initialised and red boxes because `[RCTAnimatedNode parentNodes]` is nil when it shouldn't be.
The fix is make sure all listeners are removed before node is destroyed. It is logically correct thing to do. The fix is global, for all components using `DiffClampAnimatedNode`.
Reviewed By: yungsters
Differential Revision: D40381895
fbshipit-source-id: 4f558faf8101b70552f30e6360998e902aacbc83
Summary:
Changelog:
[Internal][Added] - Add support for passing objects with `AnimatedNode` values and arrays of `AnimatedNode` elements in the `transform` styling prop.
Reviewed By: javache
Differential Revision: D40379943
fbshipit-source-id: 826b9cd0c0cfe02b55d86d1c735f8faf31196e64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
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
Nick Gerleman
Moti Zilberman
Sam Zhou
Pieter De Baets
Tim Yung
Gabriel Donadel Dall'Agnol
Samuel Susla
Pieter Vanderwerff
Abraham Romero
Mike Vitousek
Ethan Zhu
Jordan Brown
Fabrizio Cucci
Jiamin Zhu
Nick Gerleman
Sharon Zheng
Rujin Cao
Rubén Norte
Pieter Vanderwerff
Samuel Susla
Tim Yung
George Zahariev
Genki Kondo
