Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48650
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates the `Libraries/ReactNative/*.js` files to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/ReactNative` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68109193
fbshipit-source-id: 3444bf6b2152f7ed72d2923149a10041d718aaf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48807
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68436127
fbshipit-source-id: e3496fe69d66932dd4ed82f41d810f3ef1f850f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48980
Changelog: [internal]
This will be properly removed soon, but disabling for now to avoid showing up in all PRs.
Reviewed By: cortinico
Differential Revision: D68719573
fbshipit-source-id: 6a631ba2556f1399d0ade52f19b79f5a3212e007
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48054
Web debugging should be fully removed as of recent, so lets remove some of the gunk that was powering it, and checks for that environment.
I did some string searches for the following:
* isAsyncDebugging
* debugRemotely
* isDebuggingRemotely
* isRemoteDebuggingAvailable
* WebSocketExecutor
* JavaJSExecutor
* ProxyJavaScriptExecutor
* RELOAD_APP_EXTRA_JS_PROXY
* getJSBundleURLForRemoteDebugging
* onReloadWithJSDebugger
* setRemoteJSDebugEnabled
* WebsocketJavaScriptExecutor
* createRemoteDebuggerBundleLoader
1. `expo-modules-core` exposes its own `isAsyncDebugging` by checking for `nativeCallSyncHook`, but does not depend on `DebugEnvironment`.
2. `expo-dev-menu` does read `isDebuggingRemotely` from `DevSettings`.
3. Realm does a check in Native using `objc_lookUpClass("RCTWebSocketExecutor")` but will gracefully handle `nil` if it does not exist
4. Some more usages (e.g. `onReloadWithJSDebugger`) in vendored packages of `expo-dev-launcher` for RN 0.74
I created an issue for Expo mentioning both here: https://github.com/expo/expo/issues/33371
Changelog:
[General][Breaking] - Remove some web debugging remnants
Reviewed By: huntie
Differential Revision: D66553934
fbshipit-source-id: deec382b1c8bda393fddb8682aa91b26afd9fbe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48665
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Utilities to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks of the `Platform` module, which happened to touch a lot of test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Utilities` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68152910
fbshipit-source-id: 07f3a0957f1dbaf44f53974c6f28b273558406eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48901
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68562844
fbshipit-source-id: bd71a341e33d3629121aa61549139c4b1cd62c3f
Summary:
### Error message:
we got an error
```
t[n] is not a function. (In 't[n]()', 't[n]' is undefined) \n <unknown> (index.bundle:317:168:317)
```
it related the BackHandle execute handle function.
### Investigation result
our project has screen files`App.tsx`, `Dashboard.tsx`, and `Profile.tsx`.
When launching the app, the screen order is `App.tsx` -> `Dashboard.tsx`, then user can switch to `Profile.tsx`
For `App.tsx` and `Dashboard.tsx`, we just prevent the hardware button action use `usePreventHardwareBackPressEffect()` in the first line of screen code.
```js
export const useHardwareBackPressEffect = (goBack?: () => boolean): void => {
useEffect(() => {
if (goBack) {
BackHandler.addEventListener("hardwareBackPress", goBack);
return () => {
BackHandler.removeEventListener("hardwareBackPress", goBack);
};
}
return undefined;
}, [ goBack ]);
};
export const usePreventHardwareBackPressEffect = (): void => useHardwareBackPressEffect(() => true);
```
currently, `_backPressSubscriptions ` has 2 callback functions.
then user switch to `Profile.tsx` screen, and has the below code for hardwareback button and the second doesn't `return true`:
```js
// first one
usePreventHardwareBackPressEffect();
...
// second one
useEffect(() => {
const backButtonListener = BackHandler.addEventListener(
"hardwareBackPress",
() => navigate(Navigation.Login);
);
return () => backButtonListener.remove();
});
```
currently, `_backPressSubscriptions ` has 4 callback functions, include previous 2 and new 2 of `Profile.tsx`.
When the user press hardwareback button, it will navigate to the login screen, so the issue occurs:
the latest callback will be executed first, then the navigation will let the screen unmount, which will destroy the effect, so the code removing 2 hardwareBackPress callback of `Profile.tsx` by executed
```js
return () => {
BackHandler.removeEventListener("hardwareBackPress", goBack);
};
```
After the navigation ends and the loop is restored, the init `i` is 3, then `i--`, `i` is 2, then `_backPressSubscriptions[2]` is `undefined` now and executes as a function, so the app crashes.
```js
for (let i = _backPressSubscriptions.length - 1; i >= 0; i--) {
if (_backPressSubscriptions[i]()) {
return;
}
}
```
that's the issue I met.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix BackHandle callback undefined cause crash issue
Pull Request resolved: https://github.com/facebook/react-native/pull/48388
Reviewed By: blakef
Differential Revision: D67648077
Pulled By: rshest
fbshipit-source-id: 5ca685b0c0c474ef11772fd803743968ec2d912e
Summary:
Fixes https://github.com/facebook/react-native/issues/47725
Calling Appearance.setColorScheme(null) or Appearance.setColorScheme(undefined) no longer resets the color scheme useColorScheme returns like on previous rn versions.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Fix `Appearance.setColorScheme(null)` not resetting color scheme value
Pull Request resolved: https://github.com/facebook/react-native/pull/47739
Test Plan: Repo with a patch ready to test: https://github.com/sangonz193/react-native-color-scheme-patch
Reviewed By: yungsters
Differential Revision: D66230236
Pulled By: cipolleschi
fbshipit-source-id: cc668acb1fde6d30f2706fc0ab7dee5cea1c3b14
Summary:
All `removeEventListener` methods was removed https://github.com/facebook/react-native/commit/2596b2f6954362d2cd34a1be870810ab90cbb916 perviously but seems a `BackHandler` was missed
This can be a breaking change for some third-party modules.
**Migration**: Use `remove` on the EventSubscription from `addEventListener`:
```diff
useEffect(()=>{
+ const subscription = NativeModule.removeListener(name, listener);
+ return ()=>subscription.remove();
},[])
```
## Changelog:
[GENERAL] [REMOVED] - Remove `BackHandler.removeEventListener`
Pull Request resolved: https://github.com/facebook/react-native/pull/45892
Test Plan: ...
Reviewed By: huntie
Differential Revision: D65663591
Pulled By: javache
fbshipit-source-id: 01b804cd6ec77ea4916a0ced7fee551d045f1684
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47461
As titled, is overwritten later in the file.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D65546370
fbshipit-source-id: 4ea71d24e429b7bbded3e7bb7c75015a2c9d95d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47150
In https://github.com/facebook/react/pull/31314, I will change the host component type that will be synced to react-native. Notably, it will expose the issue where all the `HostComponent<mixed>` types are wrong, since it doesn't make sense to write `React.AbstractComponent<mixed>`. This diff fixes the existing usages first in prep for that typing change.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64722939
fbshipit-source-id: 14e1477090128205d8be8fc7b135a8478f94b790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47040
Updates `useMergeRefs` to support cleanup functions.
Changelog:
[General][Changed] - `useMergeRefs` and components using it (e.g. `Pressable`) now support ref cleanup functions.
Reviewed By: lunaleaps
Differential Revision: D64437947
fbshipit-source-id: b715abfa5b4236c1a7685ac023ff1d0384b6a3a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47076
The Jest unit tests for `useMergeRefs` were incorrectly implemented, leading to missing expected values. The root cause is that the test helpers were rendering to new roots instead of reusing the same root.
This refactors the test helpers to be simpler and easier to debug, and then fixes the bug described above.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D64498741
fbshipit-source-id: f0dd65f89e0c13721e83a8e38a699bc688812a0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46789
GitHub is reporting those warnings on each pull request. This clears them up as they're effectively unused.
Changelog:
[Internal] [Changed] - Remove several unused imports in Flow code
Reviewed By: cipolleschi
Differential Revision: D63757201
fbshipit-source-id: 21189136a03de8899adcbf18c8f0e29844ade340
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46742
Migrates type definitions in React Native to use the newly created `HostInstance` type instead of `NativeMethods` and `React.ElementRef<HostComponent<T>>`.
Changelog:
[General][Changed] - Simplified Flow types to use `HostInstance` (which changing nominal types).
Reviewed By: NickGerleman
Differential Revision: D63646763
fbshipit-source-id: 904894dc40da4d2e70bcb6df47018fc6248ea972
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46122
Implements a JavaScript cache for `colorScheme` in the `Appearance` module, so that we avoid potentially expensive and unnecessary native property accesses.
Changelog:
[General][Changed] - Improved `Appearance.getColorScheme` performance
Reviewed By: rickhanlonii
Differential Revision: D61567880
fbshipit-source-id: ca316946d68114b05239daa17105c85e637efe07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46120
Currently, the implementation of `Appearance` duplicates the validation logic of string `colorScheme` values multiple times.
This leads to more complicated code and also unnecessary work in certain edge cases (e.g. when `NativeAppearance` is not registered).
This refactors `Appearance` to be simpler and to do less work. I've also configured `NativeAppearance.setColorScheme` to be non-nullable because it has existed since 2023.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567881
fbshipit-source-id: 61cb51709dc716ad97ae1397105414e74fe57a28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46121
Updates `Appearance` on Android to supply the native module to `NativeEventEmitter` so that the native listener count can be managed like it is on iOS.
This was previously required by macOS and iOS. Android and Windows also already implement:
```
interface NativeModule {
addListener(eventType: string): void;
removeListeners(count: number): void;
}
```
So we should start passing `NativeAppearance` into the `NativeEventEmitter` constructor across all platforms.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567883
fbshipit-source-id: 1b3b76de9be3f35cacba1acbc43f6dcc0b41fde5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45859
"Fabric without SVCs" configuration is nearly gone, and so it doesn't make sense to need to add no-op methods, on normally Paper only code, etc to satisfy native viewconfig. These particular warnings are then more often noise, than things we need to action on.
Checking for native code to be present can also break development where users are using distributed native app, slightly older than JS.
This keeps the warning, only if static viewconfigs are missing native view config attributes (i.e. new prop would only be exposed to Paper, instead of only exposed to Fabric)
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60575253
fbshipit-source-id: 1c118274b92eb7922c0dd92df060b24e44fceb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45904
Flow will error on these dollar types soon. For all the ones changed here, they can all be further simplified.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60786768
fbshipit-source-id: e26bf0be1c4a933fc0bd8b59827e10cbd7242a83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45256
The actual stamped versions here are all strings.
Android interface for constants is untyped, and we always return a string here. iOS, we will try to parse the string into a double, which will fail for every prerelease version RN has ever published.
Platform on Windows seems to uniquely be doing the right thing.
Changelog:
[General][Fixed] - Fix Platform.constants.reactNativeVersion type
Reviewed By: robhogan, necolas
Differential Revision: D59141948
fbshipit-source-id: 9c758e5eb8796b03197258d87ec06b31018e211c
Summary:
Wrap `ReactTestRenderer.create` in `act` within `ReactNativeTestTools.expectRendersMatchingSnapshot`, as required for concurrent rendering and `IS_REACT_ACT_ENVIRONMENT` in React 19.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653136
fbshipit-source-id: 9ca0d053bda3e87dd92b762061b839d7bdd571b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44992
To allow for async `act` in a subsequent diff, make this utility method async and awaited at all call sites.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58647828
fbshipit-source-id: 3a47c57569814638c216309eed1885dd37521dde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44973
Changes `expectRendersMatchingSnapshot` to no longer make assertions about shallow rendering, because shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643365
fbshipit-source-id: 03653045a44a176095c53fc0ff27743cc8ea1820
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43992
# Changelog:
[Internal] -
While looking into implementing native DevLoadingView on non-Android/iOS platform, I realized that the current code inside `LoadingView.android.js`/`LoadingView.ios.js` is functionally identical, and can be transformed into each other with simple code transformations.
This diff:
* Renames `LoadingView` into `DevLoadingView` (as it's arguably more fitting name, given that it also relies on `NativeDevLoadingView` native module implementation)
* Merges the iOS/Android specific JS files into one
* Factors usage of the colors out of the actual logic, to better separate presentation from the business logic
From the perspective of public APIs there should be no changes.
Reviewed By: christophpurrer
Differential Revision: D55914787
fbshipit-source-id: 656311db80e5ee03f60ee7ffcf5f405ca99a9ce5
Summary:
Changelog: [Internal] Remove console logs from Metro when native Fusebox debugger console is available
React Native currently sends all `console.log` messages to Metro, which prints them to the terminal. This feature has been in place since 2019 (D15559151) but is pretty limited when compared to what's available in modern browsers. Most of the limitations can't really be fixed within the constraints of Metro's relatively simple terminal infrastructure.
With the new React Native debugger (codenamed "Fusebox") we aim to fundamentally elevate the debugging experience by shipping a well-tested version of Chrome DevTools with React Native. Chrome DevTools has a rich, interactive console, as well as a host of other debugging features we want developers to notice and use.
To that end, we plan to **strongly nudge users towards the Fusebox console from day 1**. Specifically, if we detect that Fusebox is available and is using an engine which implements CDP `console` support ( = Hermes only for now), we'll no longer send logs to Metro, and will instead display an explanatory message directing users to Fusebox.
Reviewed By: huntie
Differential Revision: D54829811
fbshipit-source-id: 2b1cdb666094f901ff4e7f42b123271be4ce7d10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43070
**Context**
The `codegenNativeComponent` function is a hint for the codegen that the file that contains it is a Native Component spec. Static ViewConfig codegen overwrites this function call by the generated ViewConfig.
If this function is not overwritten by the codegen, it has runtime behaviour that falls back to `requireNativeComponent`. At the time when this system was built `requireNativeComponent` was not supported in Bridgeless mode because it is relied on some Bridge-only functionality. That's why it outputs error in Bridgeless mode.
---
This is not the case any more, we now have interop layers which provide the functionality needed by `requireNativeComponent`.
The SVC codegen is implemented as [Babel plugin](https://github.com/facebook/react-native/tree/main/packages/babel-plugin-codegen). The are scenarios when it is not run for the native component specs:
- If the plugin is not used for whatever reason.
- If Babel is not used for whatever reason.
In order to not to regress the DevX for such cases, we've turned the error into the warning.
**Note:** we use `console.info('⚠️...` instead of `console.warn('...`. That's because `console.warn` also prints a stack trace in the console, and we didn't want to create too much noise.
Changelog: [General][Changed] - codegenNativeComponent show warning and not error if not code generated at build time.
Reviewed By: huntie, rshest
Differential Revision: D53761805
fbshipit-source-id: c924c7668e6d2e45b920672b8a309221be767a73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42402
Now that we have 2 top level directories for JS files in the `react-native` package, we need to choose where to put the native module and native component specs, because our current infra only supports a single directory.
The options we had are:
1. Keep specs in the current directory (`Libraries`). This is a problem because it encourages us to keep adding modules in this "deprecated" directory.
2. Move specs to the new `src` directory. This requires moving the current files, but from now only we can create new specs in a private directory.
3. Modify the infra to allow multiple directories. This changes the public API for something it's likely only going to be used here.
In this PR I went for option 2) because it's the most future-proof, even though it requires a little bit more work now. I created a script to automatically copy all the specs for modules and components to `src/private/specs/components` and `src/private/specs/modules`, and changed their current locations to serve as a proxy for the new location (to avoid breaking a potentially public API).
`src/private/specs` isn't meant to be their final location. We should probably still colocate native module/component specs with the rest of their code, but we can do so when we move the code from `Libraries` to `src/private`.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D52919566
fbshipit-source-id: 6de8a2d2b6077e4f884386567721c6bd2b88a5d3
Rubén Norte
Iwo Plaza
Nick Gerleman
Alex Hunt
Dawid Małecki
Ruslan Shestopalyuk
BleemIs42
Kudo Chien
Santiago
sammy-SC (Meta Employee)
D N
Sam Zhou
Tim Yung
Panos Vekris
Nicola Corti
David Prevost
Rob Hogan
Soe Lynn
Moti Zilberman
Dmitry Rykun
George Zahariev
Himanshi Goyal