[0.74][iOS] Wrong state of Touchable components with React.Suspense on New Architecture

[tboba]

Description

In react-freeze, we're using a component that wraps content into React.Suspense. However, since 0.74 RC's we can observe that some of the Touchable components are staying in a focused state, after suspensing them. It seems that after re-render, all of the native views are being created anew, leading to pass the state from the previous to the new instances of components. In our case, React tries to pass the props, but it updates the component that doesn't already exist, and it passes the unmounted state to the new one. You can see on the repro, that on re-render React loses the information about the scroll position of ScrollView, whereas the Touchable keeps the focused state on the new instance.

Steps to reproduce

1. Create Touchable component and wrap it into React.Suspense.
2. Add logic that will suspense the element (e.g. setTimeout)
3. The element should be blocked in the focused state.
4. You can additionally create a ScrollView to observe, that all of the components are being recreated during the re-render.

React Native Version

0.74.0-rc.8

Affected Platforms

Runtime - Android, Runtime - iOS

Areas

Fabric - The New Renderer

Output of npx react-native info

System:
  OS: macOS 14.4.1
  CPU: (10) arm64 Apple M2 Pro
  Memory: 294.63 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.16.0
    path: ~/.nvm/versions/node/v18.16.0/bin/node
  Yarn:
    version: 1.22.21
    path: ~/.nvm/versions/node/v18.16.0/bin/yarn
  npm:
    version: 9.5.1
    path: ~/.nvm/versions/node/v18.16.0/bin/npm
  Watchman:
    version: 2024.03.25.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.4
      - iOS 17.4
      - macOS 14.4
      - tvOS 17.4
      - visionOS 1.1
      - watchOS 10.4
  Android SDK:
    Android NDK: 22.1.7171670
IDEs:
  Android Studio: Not Found
  Xcode:
    version: 15.3/15E204a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.9
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.6
    wanted: 0.73.6
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

Unfortunately, there's no specific stacktrace that is shown during during that process.

[BUNDLE] ./index.js 

[(NOBRIDGE) LOG] Bridgeless mode is enabled
[(NOBRIDGE) LOG] Running "FabricTestExample" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}

Reproducer

https://github.com/tboba/RN-Animated-Reproducer

Screenshots and Videos

0.74 - Paper
Components are not being recreated; thus, touchable has unfocused state after re-render.

Screen.Recording.2024-04-12.at.11.47.11.mov

0.74 - Fabric
Components are being recreated (ScrollView forgot its position), but touchable has lost information about untouching.

Screen.Recording.2024-04-12.at.11.44.21.mov

[rickhanlonii]

What was the last known version that this worked in the "before" case?

[kmagiera]

We investigated this a bit more, but it was omitted in the original description but can be seen on the videos. The root cause of this issue is that with Fabric the native components are recreated after being suspended. This can be seen on the video where scroll view is being rendered that has a state (scroll position) which isn't saved into the react component. When the scrollview is suspended and unsuspended, the scroll position is reset. This is because a new view is created and replaces the previous instance of the UIScrollView that was there before suspense.

The issue with button is basically the same. The button that appears after suspense is a new button. It is in the pressed state, because that's the opacity of the button at the moment when it gets suspended. In the meantime animated runs the animation that brings the opacity back to 1, but it applies that to the "old button" and when the new one is attached back it uses that old state.

[tboba]

Hey @rickhanlonii, I've already tested this scenario on RN 0.72 and 0.73 on Fabric, but I couldn't reproduce that bug there 😕 So I can assume this was working properly up to version 0.73!
As @kmagiera said, the root cause of this bug is how React Native recreates components after being suspended. I'll correct the description to describe this issue more briefly. Thanks!

[rickhanlonii]

OK thanks for confirming that this is new in 0.74.

the root cause of this bug is how React Native recreates components after being suspended

If this is happening, it sounds like a bug. When React suspends an already committed tree, we put it into an offscreen Activity. That should maintain the state and native views while it's suspended, and when the tree-recommits, we re-use the previous state and views to commit the updated tree. So if the native views are being re-created, that's a bug. And if it was working in 0.73, that means it was previously working with the React 18 behavior that does this, so my guess is something changed in RN.

[kmagiera]

what's important to note is that it doesn't work on the new architecture only. With the old architecture and on the same version of react it works ok.

[cortinico]

@tboba @kmagiera I've spent some time investigating this. I believe that this issue is affecting iOS only at the moment (I'd like to get a confirmation from you to rule out Android though).

Specifically, here is a run of your reproducer with the JVM debugger attached at the ReactRootView.

Specifically, I'm inspecting the 4 childs of ReactRootView (the textview, the scrollview, the button and the debug overlay) to make sure that the class instances are not recreated (you can see that the @ numbers are not changing between invocations).

Screen.Recording.2024-04-15.at.15.46.06.mov

Moreover, the ScrollView is correctly rendered at the right state and the button is also not affected. If you confirm this, we'll focus our attentions on iOS as this seems to be a regression introduced in the latest versions.