Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47684
jsBundleLoader parameter was added into DefaultReactHost.getDefaultReactHost but we decided to revert this change.
We want to keep DefaultReactHost.getDefaultReactHost as simple as possible and we don't want to include this change in 0.77
changelog: [Android][Breaking] Remove jsBundleLoader from DefaultReactHost.getDefaultReactHost()
Reviewed By: shwanton
Differential Revision: D66131197
fbshipit-source-id: 7451bb55d7953d3282b23d23ad15e91bae71ff24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47598
## Changes
Now:
- in bridgeless, NativeModules.foo will also return turbo modules. And, global.__turboModuleProxy no longer exists.
- in bridge, nothing changes.
| **JS API** | **Bridge** | ***[Before]* Bridgeless** | ***[Before]* Bridgeless w/ Interop**| ***[After]* Bridgeless**
| global.__turboModuleProxy | turbo modules | turbo modules | turbo modules |**deleted**
| global.nativeModuleProxy | legacy modules | error | legacy modules | turbo + legacy modules
## Justification
This reduces the cost for adopting the new architecture:
- Prior, you had to migrate the module itself, **and** all its callsites: NativeModules.foo -> NativeFoo
- Now, you have to migrate the module itself **only**.
This simplifies the interop layer logic in bridgeless: all modules come from the same thing.
Changelog: [General][Breaking] Bridgeless: Make NativeModules.foo load turbomodules (unset turboModuleProxy in bridgeless).
Reviewed By: javache
Differential Revision: D65896934
fbshipit-source-id: 10883c292b78759fceac5bd984e0cdf8a679fc67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47653
## Context
Currently, when `nativeSourceCodeFetching == false`, `inspector-proxy` attempts to pre-fetch source maps, given the URL from a `Debugger.scriptParsed` event, and embeds them into `Debugger.scriptParsed`'s `sourceMapURL` using a data URI.
This was originally to support frontends that did not perform HTTP requests or were blocked (eg by CORS), but we're retaining it for the moment because it's more performant than lazy loading the source map.
Similarly, we perform middleware->server fetches to respond to `Debugger.getScriptSource` events.
To make these fetches for URLs that target `10.0.2.2` (ie, addressable from within an Android emulator) (etc), we rewrite `10.0.2.2`->`localhost` and perform a `fetch` from the Node process running dev-middleware.
## The problem
Consider a setup where:
- Metro is running on a remote server, listening on `8081`.
- Dev machine tunnels `localhost:8082` -> remote `8081`.
- An app is running on an Android emulator on the dev machine, with bundle URL configured to `10.0.2.2:8082`.
In this case, we'll rewrite `10.0.2.2:8082` to `localhost:8082`, which *is* reachable and correct from the dev machine, but *not* from the machine where Metro is running, so the `fetch` of a source map from the inspector proxy will fail.
## Motivation
This might seem like a niche case, but it's part of fixing a series of unsafe assumptions that currently prevent us from running DevTools on an arbitrary port.
## This fix
Preserve the current behaviour (simple `10.0.2.2`<=>`localhost`) for URLs sent to the frontend, but construct a separate, server-relative URL, using the configured `serverBaseUrl`, for `fetch` calls within dev-middleware.
Changelog:
[General][Fixed] RN DevTools: Fix fetching sources and source maps when the dev-server is remote and not tunnelled via the same port+protocol.
Reviewed By: huntie
Differential Revision: D65993910
fbshipit-source-id: a0cdcf1644e97a2af3d8583f2da2aaa51276f68c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47675
Use `request` over `fetch` in `dev-middleware`'s tests.
This is required by the next diff in the stack to spoof the `Host` header for testing purposes, which isn't permitted by the `fetch` spec.
The return type is a bit different (eg `statusCode` vs `status`, no `ok` prop), but the modifications needed are pretty straightforward.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D66005427
fbshipit-source-id: f311b0188d6d0ec220a037774fca78df5373163a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47628
`serverBaseUrl` is currently documented as:
> The base URL to the dev server, as addressible from the local developer machine
This is problematic in general because `dev-middleware` on a server doesn't necessarily know about where clients might be reaching it from, how tunnels or port-forwards are set up, etc., and this can change over the lifetime of the server and vary between clients.
Indeed, our own use of `serverBaseUrl` from both `community-cli-plugin` and internally simply sets it to the host and port the dev server is listening on - ie it's the address of the dev server accessible *from the server*.
This PR changes the docs, redefining `serverBaseUrl`, to match the way we currently specify it.
One usage where we *do* want the previously documented behaviour is in responses to `/json/list` (`getPageDescriptions`) where the URLs in the response should be reachable by a browser requesting `/json/list`.
Here, we use the request (host header, etc.) to attempt to get working base URL.
History:
It should be mentioned that this is the latest in a series of changes like this:
- https://github.com/facebook/react-native/pull/39394
- https://github.com/facebook/react-native/pull/39456
Learning from those:
- This change does *not* break Android emulators, which routes `10.0.2.2` to localhost, or other routed devices, because `/open-debugger` still uses server-relative URLs, and now formally delegates to `BrowserLauncher` to decide what to do with those URLs (internally, VSCode / `xdg-open` handles port forwarding)
- Middleware configuration is no longer required to specify how it is reachable from clients.
This sets up some subsequent changes for more robust handling of tunnelled connections.
Changelog:
[General][Breaking] dev-middleware: Frameworks should specify `serverBaseUrl` relative to the middleware host.
Reviewed By: huntie
Differential Revision: D65974487
fbshipit-source-id: 1face8fc7715df387f75b329e80932d8543ee419
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47652
## Background
When the `nativeSourceCodeFetching` capability is disabled, `inspector-proxy` rewrites URLs exchanged over CDP between device and frontend so that URLs are addressable from CDT - in particular, when using an Android emulator `10.0.2.2` (host's address from within the emulator) is rewritten to and from `localhost` (the equivalent address reachable from the host).
Previously - before we implemented `Network.loadNetworkResource`, or on old frontends that don't attempt to use that method - this worked reasonably well. A `fetch` from CDT to Metro would succeed on the rewritten URL.
## Problem
Since we implemented `Network.loadNetworkResource`, but disabled the `nativeSourceCodeFetching` capability, source fetching is broken under Android emulators. We're rewriting URLs to be frontend-relative, but then attempting to fetch them through the device, because as far as CDT is aware, `Network.loadNetworkResource` should still be tried first.
When `Network.loadNetworkResource` responds with a CDP *error*, CDT falls back to a local fetch (which would work), but when it responds with a CDP *result* of `success: false`, there is no fallback.
## Fix
This diff adds an interception guarded behind `nativeSourceCodeFetching == false`, which rejects any calls to `Network.loadNetworkResource` with a CDP error. This restores the previous behaviour from before `Network.loadNetworkResource` was implemented at all.
NOTE: An alternative approach would be to rewrite URLs back to device-relative for `Network.loadNetworkResource`, but IMO it's more correct for the frontend to respect that the device is asserting that it doesn't have that capability, and not to try to use it.
Changelog:
[Android][Fixed] RN DevTools: Fix source loading when using an Android emulator connecting to a dev server on the host.
Reviewed By: huntie
Differential Revision: D66074731
fbshipit-source-id: f2050c014cd5cfa546bff5e9d0412413a5daff35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47623
Changelog:
[iOS][Fixed] - "Reconnect DevTools" button not working sometimes
Hotfix for "Reconnect DevTools" button not working:
* T206141946 / [WP: Reconnecting dev tools does not work after restarting the app](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1107620434125533)
* T206754760 / [WP: Can't launch DevTools from Metro sometimes](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1112235073664069/)
Basically, this dialog will keep reappearing like a bad dream:
{F1960030622}
# Repro
Part 1 (Fixed in base stack D65973309)
1. Do NOT have Metro ready.
1. Build and run RNTester/FB Wilde
1. They should be using the local bundled version. App may prompt you to start Metro.
1. Start Metro
1. Go to the device Dev Menu (rage shake) and select Reload
1. Press `r` or `d` in Metro
Expected: Reload and Dev Menu work accordingly
Actual: Metro fails with `No apps connected`:
{F1960039703}
Part 2 (Fixed in this diff)
1. Open React Native DevTools via Metro `j` key or Dev Menu (rage shake)
1. Kill Metro
1. The RN DevTools should show the "disconnected" dialog
1. Start Metro
1. Click "Reconnect DevTools" in RN DevTools
Expected: reconnects
Actual: dialog reappears with an error in Metro:
{F1960043097}
Interestingly, the `r` and `d` keys from Metro works.
# Root cause(s)
Part 1: See D65973309
Part 2:
The error indicates the target/device failed to call `/inspector/device` to register itself. The subsequent calls to `/json/list` returns empty and `/open-debugger` throws.
1. But because `r` & `d` (heh) works, we can observe that there is some kind of auto-reconnect mechanism:
https://www.internalfb.com/code/fbsource/[cfe1706a60b2]/xplat/js/react-native-github/packages/react-native/Libraries/WebSocket/RCTReconnectingWebSocket.m?lines=77-82
1. We do have auto-reconnect for `j` too:
https://www.internalfb.com/code/fbsource/[cfe1706a60b2]/xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern/InspectorPackagerConnection.cpp?lines=246-254
But unfortunately it only tries once. A long-term fix would be calling reconnect recursively like the Objective-C impl above, e.g.
Edit: the long-term fix ! See V3
```
delegate_->scheduleCallback(
[weakSelf = weak_from_this()] {
auto strongSelf = weakSelf.lock();
if (strongSelf && !strongSelf->closed_) {
strongSelf->reconnectPending_ = false;
strongSelf->connect();
// Keep trying. Never. Give. Up.
if (!strongSelf->isConnected()) {
strongSelf->reconnect();
}
}
},
RECONNECT_DELAY);
```
Edit: I snuck in some time during React Native London Conf and got the long-term fix going! ✌️
{gif:7iyrns4l}
~~It appears that the current impl of `isConnected()` is not a true reflection of the web socket state. My time box for this task ran out, so we'll do a hot fix for the short-term: since we know `r` & `d` reliably reconnects, we'll piggy-back on its lifecycle to attempt reconnection. This works. I'm going on PTO for the year, so the follow-up task is up for grabs here: T207775935.~~
# PS
1. If you start the app with Metro running in step 1, this bug is not present. This is the reason why FB Wilde/Marketplace/Quantum engineers run into this more often (because its custom menu changes the JS URL after start up)
2. This auto-reconnect does not mean the RN DevTools frontend will dismiss the dialog automatically. This is only about the `Metro <> Device` in `Frontend <> Metro <> Device`.
1. Current impl in Metro/Inspector Proxy means that whenever the `Metro <> Device` connection is terminated, the `Frontend <> Metro` connection is killed.
1. This diff helps restore the `Metro <> Device` connection.
1. The `Frontend <> Metro` connection does not currently get reconnected. We can make the Frontend do so, with consideration of preserving logs/states, etc.
Reviewed By: robhogan
Differential Revision: D65952134
fbshipit-source-id: 3abd16f6a7b7ed50e8acdb7c753cc4fbd3317236
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47651
## This Change:
This change uses in the App's AppDelegate the newly generated `RCTAppDependencyProvider`, passing it to the `RCTAppDelegate`.
This change needs to be applied also to the template, when this stack lands.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Added] - Pass the `RCTAppDependencyProvider` to the `RCTAppDelegate`
Reviewed By: dmytrorykun
Differential Revision: D66074475
fbshipit-source-id: 93bf500fe37f115352ebd49d3d56955cbaeeea72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47650
## This Change:
This change generates the `RCTAppDependencyProvider` for the apps, so that the amount of changes required by the users is minimal.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Added] - Introduce the RCTAppDependencyProvider to minimize the changes required y the users
Reviewed By: dmytrorykun
Differential Revision: D66074456
fbshipit-source-id: 073022e66da53eca6bf948aeda01f17ad85793ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47649
## This Change:
This change uses the `RCTDependencyProvider` protocol created before, breaking the dependency between the RCTAppDelegate and codegen.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Breaking] - Use the RCTDependencyProvider in the RCTAppDelegate, breaking the dependency with Codegen
Reviewed By: dmytrorykun
Differential Revision: D66074438
fbshipit-source-id: 33234411a3840598b9bd16b0b71a15f75fd3c6a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47648
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
This change introduces the RCTDependencyProvider protocol to invert this dependency.
## Changelog:
[iOS][Added] - Add RCTDependencyProvider protocol
Reviewed By: dmytrorykun
Differential Revision: D66074409
fbshipit-source-id: 0d3d3f707bcb44c1f34ebeb3ae019f7ea074f60f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47664
We landed the previous change in [4dd60acb7d](4dd60acb7d), but this is breaking the OSS CI because now the two signatures do not match
## Changelog:
[Internal] - Revert make the prefetchImageWithMetadata's queryRoot nullable
Reviewed By: GijsWeterings
Differential Revision: D66096759
fbshipit-source-id: b0ce87d82edd63576df7a04c58d5aec3173ad8d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47659
Fixes https://github.com/facebook/react-native/issues/47647
There's no convenient way to access the current react context when using the new architecture. Exposing `getCurrentReactContext` allows for users to migrate without forcing the check downstream.
Changelog: [Android][Added] ReactDelegate and ReactActivityDelegate#getCurrentReactContext can be used to access the current context
Reviewed By: rshest
Differential Revision: D66094540
fbshipit-source-id: 2e504f0db3eb04e0fff5a667afed875214ba54a2
Summary:
### Problem
Setting the `tintColor` prop in ActionSheetIOS also changes the tint of disabled entries. This could make them visually indistinguishable from enabled items. The degree to which they are indistinguishable depends on the tint color.
### Solution
This new prop `disabledButtonTintColor` allows customization of disabled items' tint color.
Related PR: https://github.com/facebook/react-native/pull/31972
## Changelog:
[IOS] [ADDED] - added `disabledButtonTintColor` prop to ActionSheetIOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46883
Test Plan:
Tested in RNTester project.
<table>
<tr>
<td align="center">
<strong>Before</strong>
</td>
<td align="center">
<strong>After</strong>
</td>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/5ab251d9-3128-45e0-bb1f-907376422df0" alt="Screenshot Before" width="300"/>
</td>
<td>
<img src="https://github.com/user-attachments/assets/96f76a08-bb8d-497a-9c89-dca0e0bdbcbb" alt="Screenshot After" width="300"/>
</td>
</tr>
<tr>
<td align="center">
<strong>Before</strong>
</td>
<td align="center">
<strong>After</strong>
</td>
</tr>
</table>
Reviewed By: lunaleaps
Differential Revision: D65757069
Pulled By: cipolleschi
fbshipit-source-id: 1f51ed6927bfb4fe4e21018c541303dff44b2217
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47658
Changelog: [internal]
AppRegistry logs are showing up again in Fantom because we changed the order and now they're not necessarily showing up last.
This fixes that by filtering them out in any position.
Reviewed By: sammy-SC
Differential Revision: D66094274
fbshipit-source-id: bd37394252ee6309f7093567f9a2b73b641938ce
Summary:
in `prefetchImageWithMetadata`'s implementation in ObjC, the method's `queryRootName` is treated as being nullable. The image spec for it in JS (and the Codegened ObjC header that gets built on top of it) treat the field as not nullable. This change makes the field nullable in the spec to match up what we have in the implementation.
I also noticed that the method is not defined in the [Image props](https://reactnative.dev/docs/image) on the RN website, so perhaps we should add this there as well.
bypass-github-export-checks
## Changelog:
[IOS] [CHANGED] - make `prefetchImageWithMetadata`'s `queryRootName` nullable in the spec
Pull Request resolved: https://github.com/facebook/react-native/pull/47532
Test Plan:
yarn test:
<img width="1576" alt="Screenshot 2024-11-09 at 00 36 30" src="https://github.com/user-attachments/assets/4162ff79-1388-4f6f-9576-256fd9011fcf">
It has no iOS specific tests, so nothing to run on that side
Reviewed By: javache
Differential Revision: D65761208
Pulled By: cipolleschi
fbshipit-source-id: d050950486e9f804b65dab047d93761a610a71e7
Summary:
Currently in iOS, when focusing the multiline text input, the cursor is not automatically scrolled into view if it is out of view. This PR adds the small util to scroll the cursor into view when the text input focuses. This doesn't happen in Android due to [this](defb0bd137/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java (L360))
Original issue: https://github.com/Expensify/App/issues/48122
Original proposal: https://github.com/Expensify/App/issues/48122#issuecomment-2320769418
## 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
-->
[IOS] [ADDED] - Scroll the cursor into view when text input is focused
Pull Request resolved: https://github.com/facebook/react-native/pull/46411
Test Plan:
Code to reproduce in rn-tester
```
const TextInputWithFocusButton = () => {
const inputToFocusRef = React.useRef<React.ElementRef<typeof TextInput> | null>(null);
return (
<View>
<ExampleTextInput
ref={inputToFocusRef}
placeholder="height increases with content"
defaultValue="React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about - learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native."
multiline={true}
enablesReturnKeyAutomatically={true}
returnKeyType="go"
style={[styles.multiline, styles.multilineExpandable]}
/>
<Button title="Focus" onPress={() => {
inputToFocusRef.current?.focus();
}} />
</View>
);
};
```
Steps:
- Move the cursor of the input to end of the input text
- Scroll up the input
- Blur the input
- Click on `Focus` button to re-focus the input
Note that before this fix, the cursor is not scrolled into view
- In iOS
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://github.com/user-attachments/assets/de589cbf-158c-4e28-81d6-8412bf05ab23
</td>
<td>
https://github.com/user-attachments/assets/81c571f9-653b-49a5-9ecb-6eeaa2c54ec7
</td>
</tr>
</table>
Reviewed By: sammy-SC
Differential Revision: D62847985
Pulled By: cipolleschi
fbshipit-source-id: c0367a7fc0a7a16b30c4538e59f42d971d959357
Summary:
This pull request addresses a CMake configuration issue where an invalid escape character in file paths caused the build process to fail. Specifically, it resolves the issue in the React Native CMake configuration file where the path separator was incorrectly handled, leading to an error in the build system.
the issue is in [This Issue](https://github.com/expo/expo/issues/32955) and [This](https://github.com/expo/expo/issues/32957)
## 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
-->
[INTERNAL] [FIXED] - Corrected invalid escape character in CMake path handling
Pull Request resolved: https://github.com/facebook/react-native/pull/47641
Test Plan:
To test the changes, I performed the following steps:
1. Cloned the repository and checked out the `fix-cmake-invalid-escape-character` branch.
2. Ran the CMake build on a Windows environment where the issue was previously occurring.
3. Verified that the build process completed successfully without the "invalid character escape" error.
4. Ensured that the path handling now works correctly in CMake on Windows platforms.
Reviewed By: rshest
Differential Revision: D66073896
Pulled By: cipolleschi
fbshipit-source-id: bd2a71bb00ce5c5509ed403842c995c32f58f91d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47646
changelog: [internal]
In order to control scheduling of tests, test setup must be separated from test running. This is because of how internal scheduling of React Native is restricted until bundle is loaded via BufferedRuntimeExecutor. This is the reason for executing tests by calling global function `$$RunTests$$`. This is not a pretty solution but it is hidden within testing infrastructure and users of our test infra are not exposed to this.
There is a new method exposed to JavaScript: flushMessageQueue. This will flush everything that is inside of message queue. This is the queue where tasks are queued whenever RuntimeScheduler enqueues something by calling `runtimeExecutor_`.
Reviewed By: christophpurrer
Differential Revision: D65951894
fbshipit-source-id: 2e8e0c10fbeb998f4a51ee6d01ef229eb5f70448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47604
## Changelog:
[iOS] [Fixed] - Fixed use of view commands from layout effects
Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored.
So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler.
## What about Android?
Android employs a [retry mechanism](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L211) that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not.
iOS was built with ref commands in mind, so it doesn't have this mechanism.
Fixes: https://github.com/facebook/react-native/issues/47576
Reviewed By: javache, cipolleschi
Differential Revision: D65909191
fbshipit-source-id: 9d2a444879bee62a7b8b7d31edde450e18339b89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47636
We're cleaning up key spreads across WWW/Fbsource. Flow's `ban_spread_key_props` option allows us to fix existing spreads and prevent new ones from being added in code covered by Flow.
Here we fix spreads within xplat/js.
Also based on a unit test keeping config in sync, I've added the option to metro and RN OSS as well.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D64427942
fbshipit-source-id: db8f4aa428ce1994304b5d814b9d241d26e8d522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47638
This diff exposes exceptionHandler as a parameter of DefaultReactHost, this is necessary becuase apps using getDefaultReactHost are not able to set an exceptionHandler
We need to revisit this API as a follow up
changelog: [Android][Added] Add exceptionHandler as a parameter of DefaultReactHost.getDefaultReactHost() method
Reviewed By: alanleedev
Differential Revision: D66011047
fbshipit-source-id: 3f36aa0d064a0b1b47e9f71df55bbe466950048a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47605
changelog: [internal]
use a pointer to RuntimeScheduler instead of getting a reference to it from context container each time.
Reviewed By: javache, cipolleschi
Differential Revision: D65909100
fbshipit-source-id: c53c9b573777803f7f3077656af1dae0db7eee88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47557
Changelog: [internal]
Not published as a bugfix because this API isn't enabled in OSS yet.
Reviewed By: sammy-SC
Differential Revision: D65769326
fbshipit-source-id: 165d58304d8214c583fbc162d8888095e9f068aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47612
Changelog: [internal]
Just using babel-register so we can use Flow types in the code for the RN integration tests runner.
Reviewed By: sammy-SC
Differential Revision: D65948801
fbshipit-source-id: 6c54b0463fe4b71c818ff1c4faa973cc8b13b5d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47615
Changelog: [internal]
Fixes `.not` not being applied in some cases, and no logging the "not" label in case of error, and `.toBe` being flipped.
Reviewed By: javache
Differential Revision: D65952221
fbshipit-source-id: 030c0597b661d34e6324d69e5676375150a74f2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47624
Changelog:
[iOS][Fixed] - fix `r` & `d` not working from Metro sometimes
While investigating these bugs, I've come across some cases where `r` (Reload) & `d` (Open Dev Menu) not working in Metro.
* T206141946 / [WP: Reconnecting dev tools does not work after restarting the app](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1107620434125533)
* T206754760 / [WP: Can't launch DevTools from Metro sometimes](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1112235073664069/)
This is because when we
1. Start app without Metro
1. Start Metro
1. Reload from Dev Menu (rage shake)
`RCTPackagerConnection` did not get notified about the change in bundle URL. It'd stay "listening" to the commands from the local bundle instead of Metro
.
Reviewed By: robhogan
Differential Revision: D65973309
fbshipit-source-id: a67a58b405bb78dfe56b814f2ec0bbee9e530e46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47596
Improves the Flow type of `usePressability` so that if the `config` argument is non-nullable, the return value is non-nullable. This helps reduce unnecessary null checks.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D65908791
fbshipit-source-id: 77de4391d8141d698a5689e617b692b337d01ae5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47588
This is unnecessary - we can pass the params directly instead of first populating them in a Rect.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D65843834
fbshipit-source-id: 92bb3faa622bba81792fe92e357bc1667894d4ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47595
Enables the `useInsertionEffectsForAnimations` feature flag by default. This changes `useAnimatedProps` to enqueue updates to the `AnimatedNode` graph in `useInsertionEffect` instead of `useLayoutEffect`.
The main motivation for `useInsertionEffect` is to avoid unmounting `AnimatedNode` graphs when an `Activity` subtree becomes hidden.
Both `useInsertionEffect` and `useLayoutEffect` occur during the commit phase. Although they occur at different moments in the commit phase, the different is difficult to observe and unlikely to impact product code.
One observable impact is that with `useInsertionEffect`, animations can now be started from layout effects.
Changelog:
[General][Changed] - The `AnimatedNode` graph will not occur during the insertion effect phase, which means animations can now be reliably started during layout effects.
Reviewed By: mdvacca
Differential Revision: D65906157
fbshipit-source-id: d09b2f1b76079eecafbed8c6f5d8ee4695a1f81c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47551
## Summary
I'm working to get the main `react-native` package parsable by modern
Flow tooling (both `flow-bundler`, `flow-api-translator`), and one
blocker is legacy `module.exports` syntax. This diff updates files which
are [synced to
`react-native`](https://github.com/facebook/react-native/tree/main/packages/react-native/Libraries/Renderer/shims)
from this repo.
## How did you test this change?
Files were pasted into `react-native-github` under fbsource, where Flow
validates ✅.
DiffTrain build for [5c56b873efb300b4d1afc4ba6f16acf17e4e5800](5c56b873ef)
Test Plan: Sandcastle tests
Reviewed By: sammy-SC
Differential Revision: D65672576
Pulled By: huntie
fbshipit-source-id: 3d1f2eee0a4872d6a167cbc10e9f022e20f2bdc3
Summary:
This PR adds support for negative values in enums.
Currently when we try to use an enum with negative value:
```ts
enum MyEnum {
ZERO = 0,
POSITIVE = 1,
NEGATIVE = -1,
}
export interface Spec extends TurboModule {
useArg(arg: MyEnum): void;
}
export default TurboModuleRegistry.get<Spec>('Foo');
```
It will fail:
```
Enum values can not be mixed. They all must be either blank, number, or string values.
```
This is because negative values are parsed as `UnaryExpressions` which have `-` operator in front and value as argument.
With the new approach codegen properly generates enums with negative values.
## Changelog:
[GENERAL] [ADDED] - Codegen: Support negative values in enums
Pull Request resolved: https://github.com/facebook/react-native/pull/47452
Test Plan: I've added tests to see if everything is working properly
Reviewed By: vzaidman
Differential Revision: D65887888
Pulled By: elicwhite
fbshipit-source-id: edb25f663dc58afa68c69cb84a47cfc67fc1f7e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47577
Changelog: [Android][Fixed] ensure setSelection in onAttachedToWindow is within text range
Reviewed By: javache
Differential Revision: D65824906
fbshipit-source-id: 3dc7d27bf4f9a10762f11fa4a0bcae8af13c7db7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47585
We have two classes named ReactFontManager and during the Kotlin migration this got mixed up.
Changelog: [Android][Fixed] Fixed crash in legacy ReactFontManager
Reviewed By: fabriziocucci
Differential Revision: D65877606
fbshipit-source-id: d9dc4f29045ad377adb216216334af5501c5546e
