Summary:
Sets up an injection mechanism for experimenting in production with an alternate implementation of `createAnimatedComponent`.
This will be used to implement and refine a new `createAnimatedComponent` that is compatible with concurrent rendering.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28799739
fbshipit-source-id: 46ba2dd6137f7bf73ce8a659698533ed3985516f
Summary:
This check will never pass because `this._propsAnimated` contains an instance of `AnimatedProps`, but `nextProps` contains an object literal containing the new props.
Changelog:
[Internal]
Reviewed By: JoshuaGross, TheSavior, kacieb
Differential Revision: D28271627
fbshipit-source-id: c563eec1eeaee5eb84bb01525313b46db502225a
Summary:
Decouples `__attach` from the constructor in `AnimatedProps`.
This change will enable the instantiation of `AnimatedProps` (and subsequent invocation of `__getValue()`) without having to trigger side effects until after mount or update. This is important in order for `Animated` to ever become safe for Concurrent Mode.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28271628
fbshipit-source-id: 6ccfed6de79382cecdfa6939c7dad3134e1ecaaa
Summary:
This change caused crashes in animations on some surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013969
fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
Summary:
In 0.62, `createAnimatedComponent` was changed to use `forwardRef` instead of requiring callers to use `ref.getNode()`. In order to preserve backward-compatibility, `ref.getNode()` was monkey-patched onto the returned ref, if possible, to return the `ref` and output a console warning.
Three major (well, technically, minor) releases later, we are dropping support for `getNode()`. Calling it on the `ref` of an animated component will begin to fail after this (unless the underlying component itself actually implements a `getNode()` method on its imperative handle).
Changelog:
[General][Removed] - Removed `getNode()` from animated component refs.
Reviewed By: nadiia
Differential Revision: D27979882
fbshipit-source-id: 885c3dbf4f2749c994fc2662dd6f16ff3dd887c7
Summary:
D27682424 (ea1ff374de) updated how animated node batches are executed in Fabric. On Paper, these batches were controlled by native module in some places (batch was executed ~every 2 frames), but some animations were switching animation batching control to JS globally there as well.
This change updates two things:
- If batching is controlled by native, it makes sure batches are calculated correctly.
- At the same time, this change switches control for animation node batching to JS, aligning it with Fabric.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27939659
fbshipit-source-id: d6251bce2a303a4a007dc10297edc0175cc4b348
Summary:
"The instance should not stick around after unmount..." - Tim Yung, 2021
I have a hypothesis that, if a component instance of an animated component sticks around after unmount, it could cause memory leaks due to references to Fabric ShadowNodes across the JSI (this would not impact non-Fabric... in theory).
Wild guess. If OOMs disappear then maybe this hypothesis is correct, but it's a long shot. I figure there's ~no harm in doing this cleanup here anyway.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26650348
fbshipit-source-id: 90633db650b65755cacfb52344e7b53e46c9b125
Summary:
There's logic in Animated JS that prevents flattening of animated views in Fabric. However, we cannot actually detect Fabric vs non-Fabric in the first render pass; in the past we defaulted to assuming non-Fabric. Now we assume Fabric for View flattening purposes.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D26647393
fbshipit-source-id: c91b51aeeb4f352cc502bc018f086e36fd1ffd85
Summary:
The `isFabric` method used in createAnimatedComponent is unreliable (another reason in a long list of reasons why you should not duplicate this code elsewhere, and why we want to delete it ASAP).
In particular, during the first render, the ref component has not been set yet, so we /cannot/ detect if the component is Fabric or non-Fabric and assume it's non-Fabric.
In Fabric, this causes `collapsable` and `nativeID` values to change after the first render.
To reduce this re-rendering, but not eliminate it for all components, I've introduced a flag that indicates if a component will /never/ be flattened. In particular, Image components, ScrollViews, Text cannot ever be flattened,
so we should always pass `collapsable:false` and the same nativeID prop for those components. For Animated <View>s and other components, the re-rendering issue is still a problem in Fabric for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25720322
fbshipit-source-id: fe3234d8ae974911a2b5f82e4f6a093216f43d4b
Summary:
In D24521951 (2ff1d4c041) I refactored the JS-side queueing for NativeAnimated API calls, and used randomized IDs for queueing. This could cause bugs or unexpected behavior, and potentially crashes, if there's ever a collision in random numbers generated or
a collision between random number and one of the deterministic numbers generated in createAnimatedComponent.
In this diff I make both of them namespaced with a string, and deterministic, to eliminate any potential collisions. This could also be slightly faster (but not meaningfully) since we're not relying on Math.random.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24553557
fbshipit-source-id: 8b765e21597ad4f8e641453c1f9f90bdf1ee022f
Summary:
This small PR fixes few "no-unused-var" issues and and removes two old entries for no longer existing files from the `.eslintignore`.
## Changelog
[Internal] [Fixed] - Lint: fix few "no-unused-var" warnings for imports
Pull Request resolved: https://github.com/facebook/react-native/pull/30157
Test Plan: Successfully run of `yarn lint` script. Warnings count has been reduced from `61` to `58`.
Reviewed By: yungsters
Differential Revision: D24288226
Pulled By: appden
fbshipit-source-id: 06e4ef015a331e3f2eac3b9aa6f757a3764e3ed9
Summary:
I believe the old method of queueing these operations for Fabric is causing crashes because "connectNode" is on a separate JS queue from setting up nodes.
In hindsight, this seems silly. We must ensure that nodes are created before they're connected, and we weren't doing that?
Using a single queue is conceptually simpler, should be easier to reason about, and should fix some crashes.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24521951
fbshipit-source-id: f6c38ac0023faa28414063d8b96daf32ba95524d
Summary:
Removes the legacy `react-animated` package configuration and collapses the `Animated/src/` directory into `Animated/`.
Also, reconfigures all references to `Animated/src/` to just be `Animated/`.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22450848
fbshipit-source-id: 9fd4861e9f357d817d82e9fec71967a2936a3830
Tim Yung
Andrei Shikov
Nadiia D
Joshua Gross
simek
Samuel Susla