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
Summary:
`Easing` only has static properties and is never constructed or subclassed, so there doesn't seem to be any reason for it to be a class instead of an object.
as a class, Flow errors about `method-unbinding` on every single use of it.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33774944
fbshipit-source-id: c0bd2e3d7a78e538f95b88b2b1b12d301c8f590c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32736
The ability to pass an additional property bag to further configure NativeAnimated is useful for a few reasons, e.g., experimentation with multiple implementations of the NativeAnimated module.
The specific use case this solves is on react-native-windows, where there are two underlying animation graph options, one "optimized" animation graph that uses UI.Composition, and another similar to the approach to iOS and Android that uses a frame rendering callback.
The platform configuration can be supplied to the animation node when `useNativeDriver` is set to `true`, and we pass the platform configuration object to the connected AnimatedValue and all it's children.
Changelog:
[General][Added] - Option to supply `platformConfig` to NativeAnimated
Reviewed By: yungsters
Differential Revision: D32988285
fbshipit-source-id: ab8a7bbf197573fc9e9a4737c255f124321295ac
Summary:
Flow currently allows duplicate members on classes. At runtime the "last" member wins out and all previous values for the member are discarded.
This diff manually removes duplicate members, and fixes resulting flow errors by converting methods to arrow function properties.
Reviewed By: pieterv
Differential Revision: D33664966
fbshipit-source-id: 0f712ac96af4df593c0918fcbadd70624ddde4a6
Summary:
AnimatedValue fires a callback with the current value (raw value + offset) after calling it's `stopAnimation` method. The `_value` field on the `AnimatedValue` node is not necessarily kept in sync with the NativeAnimated value node, so the value provided to the callback may be out of sync.
This change checks if the `AnimatedValue` is a native node and passes the callback to the `NativeAnimatedAPI.getValue` callback, defaulting to the previous current JS node state if the node is not native.
Changelog:
[General][Fixed] - AnimatedValue.stopAnimation callback with correct value for NativeAnimated
Reviewed By: yungsters
Differential Revision: D32968572
fbshipit-source-id: b83f86eabe5456f762a15bc29cacb43f84513f6c
Summary:
This diff runs the codemod to add type annotations to function parameters in preparation for Flow's local type inference (LTI) project. I ran the codemod over xplat/js and reverted any files that had flow errors in them. See the list of commands run to see the regeneration of various files.
Changelog:
[Internal][Changed] - Added type annotations
Reviewed By: yungsters
Differential Revision: D32075270
fbshipit-source-id: 6a9cd85aab120b4d9e690bac142a415525dbf298
Summary:
This diff makes the manual changes necessary to fix many of the errors in the stacked diff codemod.
See https://fb.workplace.com/groups/flowlang/posts/917522612186736 for details on this effort.
Reviewed By: bradzacher
Differential Revision: D31615035
fbshipit-source-id: 179b2df516833d59873b9003350f81eb4a6b4e9d
Summary:
Single and composite animations were handled inconsistently in AnimatedMock. Also added a guard to prevent callbacks from triggering additional animations, since we had a test-scenario that did exactly that.
Changelog:
[General][Fixed] - Composite animations will now be ran immediately when the app is in testing mode
Reviewed By: yungsters
Differential Revision: D31826967
fbshipit-source-id: a6416b42e227fe79f5c3a55a9c51beb8451874f8
Summary:
The documentation of back easing contains a old link that
is now stale. I'm updating it to link to https://easings.net/#easeInBack
Fixes https://github.com/facebook/react-native/issues/32419
Changelog:
[Android] [Fixed] - Fixes documentation for back Easing animation
Reviewed By: hramos
Differential Revision: D31728560
fbshipit-source-id: 99f7aa60d3748af5429b4ae1aa6cbd79326c5fe6
Summary:
Implement par of the discussion https://github.com/react-native-community/discussions-and-proposals/discussions/411, except the `.nvmrc` part, this includes:
- Setting `.ruby-version` in the main project and also `template/`
- Fixing the CocoaPods version with a project-level `Gemfile` and also `template/Gemfile`
- Using all `pod` executions from `bundle exec pod`, using the determined version
- Script to manage and update the ruby version
## Changelog
[iOS] [Added] - Gemfile with CocoaPods 1.11 and ruby-version (2.7.4)
Pull Request resolved: https://github.com/facebook/react-native/pull/32303
Test Plan: Build for iOS and run all CircleCI tests to see if nothing changed
Reviewed By: RSNara
Differential Revision: D31344686
Pulled By: fkgozali
fbshipit-source-id: 25c63131ca9b16d3cf6341019548e0d63bdcaefe
Summary:
When we were iterating on the Fabric renderer, animated components went through some iteration to ensure that animated shadow nodes were not flattened away. At the time, `collapsable` was not supported on iOS, even in Fabric, because the legacy renderer would not publish the `collapsable` prop on the view config.
This has since been fixed and `collapsable` is supported on both Android and iOS. We no longer need the `nativeID` workaround to prevent view flattening.
For use cases of the JavaScript driver and legacy renderers, this change will cause views which used to be flattened to no longer be flattened. This seems like an appropriate change considering the direction that we are moving (in which everything is eventually transitioned to using the Fabric renderer).
Changelog:
[Android][Changed] - Native views backing Animated.View (w/ JavaScript-driven animations) will no longer be flattened; this should be a transparent change.
Reviewed By: lunaleaps, mdvacca
Differential Revision: D31223031
fbshipit-source-id: 48dc63471eef406f4c215bfea0b3ef82a05d4b24
Summary:
Changelog: [Internal]
This diff add types to some of the common globals so uses of
them through `global` are now typed.
All the globals are marked as read-only for their intented uses.
However, some of them do have write cites (mostly are in tests to
deliberately set up a special test environment). Those write cites
are considered as "necessary evil" and annotated as `FlowFixMe`.
Reviewed By: yungsters
Differential Revision: D30158145
fbshipit-source-id: 93a99063361a4b7a1e33d9fc97a661be30a4d8f9
Summary:
Changelog: [internal]
Make sure the order of call is preserved for `NativeAnimatedModule`. The order of calls to NativeAnimatedModule needs to be preserved because its internals depend on it. For example, if you `getValue` is called before `createAnimatedNode`, it causes a crash.
To resolve it, we need to enqueue `getValue` onto operationQueue.
Reviewed By: JoshuaGross
Differential Revision: D30035911
fbshipit-source-id: bbd698a96cada5d2b1312a1a689ca99b04a07cdc
Summary:
Add animation queuing back into createAnimatedComponent_EXPERIMENTAL.js, which is a concurrent-safe version of createAnimatedComponent.
T93269035 for details on why this is needed.
# How does this work?
In the old createAnimatedComponent, Animations were queued by calling `setWaitingForIdentifier` before render, and then calling `unsetWaitingForIdentifier` after render.
In this diff, instead we are calling `setWaitingForIdentifier` in an `useLayoutEffect` before calling `useAnimatedProps`, and we are calling `unsetWaitingForIdentifier` in a `useEffect` after `useAnimatedProps`. So the ordering for the effects are:
1. `useLayoutEffect` with `setWaiting`
2. `useLayoutEffect`s in `useAnimatedProps`
3. `useEffect`s in `useAnimatedProps`
4. `useEffect` with `unsetWaiting`.
There's a React guarantee that **if one effect is called, all of them will be called**, so we don't have a concern about the queue getting locked.
## **Main concerns:**
1. This works in my test cases, but it's not the same behavior as the old createAnimatedComponent (which is wait before and unset wait after render). This may still be ok because the relevant side effects in render from that component have been moved to `useLayoutEffect` or `useEffect` in `useAnimatedProps` (so the ordering is still the same?).
2. I'm not sure about the ordering of `onLayoutEffect`, `onLayout` callbacks, and `useEffect`. createAnimatedComponent_EXPERIMENTAL doesn't use `onLayout`, but with this new method of queuing, **`onLayout` calls will likely be called before the animation queue has been flushed**. It's not clear to me whether this is bad.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D29467458
fbshipit-source-id: 2be23a8968404526d0fa394a7879fda8b5ffbfdc
Summary: Changelog: [Internal] - Animated.event from my limited understanding attaches Animated.Values to native views. In terms of animation, Animated.Values are already handled by AnimatedMock to skip interpolation.
Reviewed By: GijsWeterings
Differential Revision: D29241590
fbshipit-source-id: 98650883dad53d6f77dbc398ba0cac903194deca
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Creates a `useAnimatedProps` hook that is compatible with concurrent mode, and uses this in `createAnimatedComponent_EXPERIMENTAL`.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28390393
fbshipit-source-id: d8aa471507a5d096832b93caf63a24f71733deda
Summary:
Creates an experimental stub implementation of `createAnimatedComponent` to be implemented in future commits.
Changelog:
[Internal]
Reviewed By: lunaleaps, kacieb
Differential Revision: D28799738
fbshipit-source-id: dc3fbee557db353de6807bd87561f8f372d7cab5
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 pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Fixes https://github.com/facebook/react-native/issues/28517
Animated.loop needs to reset the animation after each iteration but currently, natively driven animations are not getting reset properly.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Fix natively driven animations not getting reset properly
Pull Request resolved: https://github.com/facebook/react-native/pull/29585
Test Plan: Tested within RNTester
Reviewed By: kacieb
Differential Revision: D28383538
Pulled By: yungsters
fbshipit-source-id: 40790ad8f825c402afc3515ef6afc00570704109
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:
NativeAnimationModule on Android is using batches to combine related updates together. In Fabric, this process is controlled by JS, which schedules starts batching when Animated component props are about to be updated.
In rare cases when there's no prop update (like calls to `setValue` on `AnimatedValue`), changes weren't applied until the next batch was scheduled. This change ensures that such changes get applied directly.
This problem doesn't happen on iOS or non-Fabric surfaces, because they use per-frame scheduling instead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28100641
fbshipit-source-id: 87b3acb3a8de131cdcb2104dc121d40eccfbc29d
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:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
This change contains the suppressions for the up coming v0.142.0 Flow release.
The new suppressions are a result the following changes:
* Disallow flowing functions or inexact objects to indexed objects to improve object soundness. This can cause errors if you are passing a function or inexact objects when an indexed object is expected.
* Flow now processes imports before checking the body of a file. In some rare cases this can expose previously skipped errors due to the processing order.
Reviewed By: mroch
Differential Revision: D25820434
fbshipit-source-id: 59cc1d852ffc8cc39f0d5112ce485fb33f05c092
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