react-native-reanimated new architecture adoption

[tomekzaw]

We are happy to announce that Reanimated supports Fabric as of 3.0.0-rc.0 release. 🎉

For more details, check out our Announcing Reanimated 3 blog post.

---

React Native Reanimated integrates quite closely with the renderer system so we needed to rewrite some parts specifically for Fabric and that's exactly what we have been doing for the past few months.

Here's the current state of feature migration:

• ✅ secondary JS VM & worklets
• ✅ animating UI props (e.g. opacity or backgroundColor)
• ✅ animating native props (e.g. width or margin)
• ✅ useAnimatedScrollHandler
• ✅ measure & scrollTo in worklets
• Layout Animations – TODO
• ✅ integration with Gesture Handler
• ✅ simultaneous support for Paper and Fabric, autoinstall etc. – should be easy since we've already done it for react-native-screens and react-native-gesture-handler
• profiling & optimization – after RC

Pull requests to React Native:

• Fix dynamic_cast (RTTI) by adding key function to ShadowNodeWrapper and related classes facebook/react-native#33500 - we've had some troubles with dynamic_cast<ShadowNodeWrapper> due to RTTI not working properly between shared library boundaries and this PR to React Native core enables third-party libraries to integrate with C++ part of Fabric (edit: merged, thanks!)
• Pass mutation list to RCTMountingTransactionObserving callbacks facebook/react-native#33510 - this PR should eliminate some major difficulties blocking us from implementing Layout Animations for Fabric (edit: merged, thanks!)
• Expose private node management methods in UIManager facebook/react-native#33688 - this PR allows us to easily obtain UIManager and also intercept and elegantly handle events in C++ (edit: merged, thanks!)

With Fabric release we also dropped support for Reanimated 1.

[cortinico]

Right now we're stuck on Android build config but once we resolve this issue we'll prepare the Fabric branch so other early adopters of the new architecture can check it out.

Is this something you can share more @tomekzaw or that we can support you in some form?

[ShikaSD]

The main problem we have now is that when animating layout props, React and Reanimated overwrite each other's changes.

(Just thinking aloud here) Would it be possible to use State updates for those nodes instead to override properties? I am not sure if Reanimated uses built-in or custom views, but state was created specifically for merging React prop updates and native changes together

[ShikaSD]

For example, in React Native Gesture Handler we also need to access ShadowNode in order to see if the corresponding view will get flattened by checking ShadowNodeTraits::FormsStackingContext

I know it doesn't solve the underlying problem, but maybe for this case it makes sense to enforce unflattening of nodes gesture recognizer is attached to (with collapsable=false? That's what we do for different event handlers internally as well.

[ShikaSD]

JS VM that is used only from the UI thread to synchronously run user-defined JS functions (so-called worklets).

What kind of information do you pass about the node there? How the worklet knows which props to interpolate/which node those updates belong to?

[tomekzaw]

Would it be possible to use State updates for those nodes instead to override properties? I am not sure if Reanimated uses built-in or custom views, but state was created specifically for merging React prop updates and native changes together

Reanimated uses built-in RN View native component but wrapped with some additional JS logic (here) using createAnimatedComponent function (here) and exported from react-native-reanimated as Animated.View.

We could implement Animated.View as a native component that extends the native part from RN's View using inheritance and just overwrite some of the methods, but we would still need to copy large chunks of JavaScript code from RN and we would like to avoid it if possible.

I need some more time to familiarize myself with the concept of State (I thought it only represents some internal state of native views like offset for ScrollView) but it sounds promising as it's kept in ShadowNodeFamily, can be updated using setMostRecentState and also is properly synchronized. Can you please show me where "merging React prop updates and native changes together" happens in the code?

I know it doesn't solve the underlying problem, but maybe for this case it makes sense to enforce unflattening of nodes gesture recognizer is attached to (with collapsable=false? That's what we do for different event handlers internally as well.

We already set this property here and it works well when the child of <GestureDetector /> is a native component (e.g. <View />). But when the child is a functional component, I don't think we have a way to set collapsable={false} for the most outer component inside (if this is somehow possible, please let us know). That's why we only detect such cases using shadow tree (since from React ref we can obtain the ShadowNode of the most outer native component from the functional component) and tell users to set collapsable={false} on their own.

We cannot wrap the functional component within <View collapsable={false} /> automatically because of two reasons. Firstly, if the functional component has a margin, then if we attach the gesture handler to the wrapper view, the gesture will also be able to capture the touches on the area of margin. Secondly, we think there may be some issues with position of the component when using position: relative.

What kind of information do you pass about the node there?

On Paper, we identify the component by its viewTag, which we obtain from React ref in the main JS runtime. On Fabric, we do the same but using ShadowNodeWrapper instead of view tags.

How the worklet knows which props to interpolate/which node those updates belong to?

Here's a short example from Reanimated docs. Firstly, you need to call useAnimatedStyle hook to define animated styles depending on shared values. Shared value can be written and read from both JS VMs. You can update its value immediately using assignment operator (e.g. offset.value = 100;), interpolate it (e.g. offset.value = withSpring(100, { duration: 300 }); or calculate the value based on other shared values (e.g. offset.value = 100 * foo.value + 200;). The callback in useAnimatedStyle needs to be a worklet since this function will be called in the secondary JS context synchronously from the UI thread. Also, you can skip the 'worklet'; directive here as Reanimated's Babel plugin automatically recognizes useAnimatedStyle callbacks as worklets. Once you have "animated styles", you can simply pass them to style prop of Animated.View component, like here: <Animated.View style={[styles.box, animatedStyles]} />.

Reanimated first calculates the new values of all shared values (using so-called "mappers" which sort shared values topologically according to dependencies between them) and then detects which animated styles are affected. This part of Reanimated has already been implemented using JSI and works well both on Paper and Fabric (as it's arch-generic).

Now, for each affected animated style, this method gets called with ShadowNode and new styles as plain JS object. The thing we don't know yet is how to safely update the props and re-calculate layout so that RN won't overwrite these changes on next render.

[ShikaSD]

Can you please show me where "merging React prop updates and native changes together" happens in the code?

I think it is a result of unfortunate wording, the props and state are kinda separate, and as you pointed out, we keep the track of the most recent state updates in the ShadowNodeFamily. What I meant by "merging" prop and native changes together is the fact that ShadowNode always has the most recent state even for stale nodes, meaning that it will see the state update no matter what. I don't think we change props directly through this mechanism though.