Skip to content

Commit 133ccdc

Browse files
cortinicofacebook-github-bot
authored andcommitted
Make sure the Native RuntimeScheduler is initialized on Old Arch (#37517)
Summary: Pull Request resolved: #37517 Fixes #35778 We got reports of regressions on `useEffect` starting from 0.69+ when on Hermes. The issue seems to be caused by a bump of the `scheduler` package from 0.20 to 0.21. In [email protected], the method `setImmediate` gets called if available (see facebook/react#20834). This causes React Native to use Microtasks which ends up in changing the semantic of useEffect. The solution is to use the Native RuntimeScheduler properly. On Paper specifically, we never initialized it as it's effectively initialized by the TurboModuleManagerDelegate. Here I trigger the initialization of it on Paper as well. Changelog: [Android] [Fixed] - Make sure the Native RuntimeScheduler is initialized on Old Arch Reviewed By: sammy-SC Differential Revision: D46024807 fbshipit-source-id: d72cd774df58410467644cddeaaf37e3c227b505
1 parent c396bc7 commit 133ccdc

File tree

2 files changed

+16
-0
lines changed

2 files changed

+16
-0
lines changed

packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1358,6 +1358,15 @@ private ReactApplicationContext createReactContext(
13581358

13591359
reactContext.initializeWithInstance(catalystInstance);
13601360

1361+
if (ReactFeatureFlags.unstable_useRuntimeSchedulerAlways) {
1362+
// On Old Architecture, we need to initialize the Native Runtime Scheduler so that
1363+
// the `nativeRuntimeScheduler` object is registered on JS.
1364+
// On New Architecture, this is normally triggered by instantiate a TurboModuleManager.
1365+
// Here we invoke getRuntimeScheduler() to trigger the creation of it regardless of the
1366+
// architecture so it will always be there.
1367+
catalystInstance.getRuntimeScheduler();
1368+
}
1369+
13611370
if (ReactFeatureFlags.useTurboModules && mTMMDelegateBuilder != null) {
13621371
TurboModuleManagerDelegate tmmDelegate =
13631372
mTMMDelegateBuilder

packages/react-native/ReactAndroid/src/main/java/com/facebook/react/config/ReactFeatureFlags.java

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,13 @@ public class ReactFeatureFlags {
5050
*/
5151
public static volatile boolean unstable_useFabricInterop = false;
5252

53+
/**
54+
* Should this application always use the Native RuntimeScheduler? If yes, we'll be instantiating
55+
* it over all the architectures (both Old and New). This is intentionally set to true as we want
56+
* to use it more as a kill-switch to turn off this feature to potentially debug issues.
57+
*/
58+
public static volatile boolean unstable_useRuntimeSchedulerAlways = true;
59+
5360
/**
5461
* Feature flag to enable the new bridgeless architecture. Note: Enabling this will force enable
5562
* the following flags: `useTurboModules` & `enableFabricRenderer`.

0 commit comments

Comments
 (0)