-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change in 'key' prop leads to reset to original style/animated value after animating a view in 0.72 #38510
Comments
|
Fixed. |
This commit updates useAnimatedPropsLifecycle to first attach the animated node instantly, rather than waiting on useLayoutEffect. This is done only once (by adding hasMountedRef) and also adds another ref (hasInitiallyAttached) which is checked in useLayoutEffect, to avoid running node.__attach() twice before the first render. This seems technically equivalent to the UNSAFE_componentWillMount functionality that was in createAnimatedComponent.js prior to RN 0.72 and the move to the updated useAnimatedProps.js. Fixes an issue (facebook#38510) where changing the key of an animated component would result in a reset of animated values (and basically not re-attaching in time for *native* animations)
Submitted (first ever) pull request with a fix. It appears to pass all tests and fixes the above issue - but I must admit that my knowledge of how native animation works is limited - hope this doesn't cause issues... The pull request has a minor change to the way useAnimatedProps works. I found the underlying issue was related to a change in 0.72, with the migration to an improved useAnimatedProps. Prior to 0.72, createAnimatedComponent.js (which had some of the functionality that is now in useAnimatedProps) attached the animated node instantly in UNSAFE_componentWillMount. This seemed to be missing from the updated useAnimatedProps, which attached node only via useLayoutEffect, and created issues with natively animated components after remounting via a "key" change. |
As a note: this issue is still present in React Native 0.74.1. Despite being a bit of an anti-pattern fix, Im using a patch derived from the linked PR in production without any noticeable issues so far. Looking forward to a better alternative though. |
Description
After executing an animation (such as Animated.timing) with useNativeDriver set to true, changing the "key" prop (which causes a remount) in a child view, that utilizes the animated value, results in a reset to the view's original style. The updated Animated.Value is not being reflected in the UI.
This bug seems to be specific to version 0.72.
Note: This issue bears similarity to #34665, but the bug I am reporting only occurs in version 0.72 and exclusively upon changing the "key" prop (remounting vs replacing the style). This suggests potentially different root causes.
072.mp4
As you can see the view jumps back to its original position (after key change).
070.mp4
(Note: recorded in 0.70, but same result in 0.71)
React Native Version
0.72.3
Output of
npx react-native info
Steps to reproduce
Expected result: The Animated.View should reflect the updated Animated.Value.
Actual result: In 0.72, The Animated.View reverts to its original display, ignoring the changes in Animated.Value. Inspecting the value with devtools confirms the value is indeed at 10, but the expected interpolated style is not being applied.
Snack, code example, screenshot, or link to a repository
https://snack.expo.dev/@kducros/trusting-banana
Note: As of time of posting, Snack has not been updated to Expo SDK 49 (with RN 0.72), so this shows expected behaviour.
The example below has a simple animation, and sets the state on completion, which is used in the "key" prop.
App.js:
The text was updated successfully, but these errors were encountered: