Summary:
Now, handleError can be called with a JSError that wraps a non-error object!
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64706198
fbshipit-source-id: 562ed7d4e2a13eaef48acfdf3499296462e54166
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45626
I'm deleting CoreFeatures class and all its imports because it was fully replaced by ReactNativeFeatureFlags
Changelog: [Internal][Removed] Delete CoreFeatures class in favor of ReactNativeFeatureFlags
Reviewed By: rubennorte
Differential Revision: D60137380
fbshipit-source-id: 8bf918cdd1ce66e315aa95e1c5a28879445ff9f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47179
In this diff I'm exposing the new parameter (JSBundleLoader) as parameter of DefaultReactHost.
changelog: [Android][Breaking] Added JSBundleLoader as parameter of DefaultReactHost
Reviewed By: cortinico
Differential Revision: D64381501
fbshipit-source-id: dd0d56441802f7db53c67c659bbcae63c4b1b613
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47128
Delete CompositeReactPackage from RN, these classes were deprecated for a long time and they can be deleted now, there are no internal usages
changelog: [Android][Breaking] Deleting deprecated CompositeReactPackage
Reviewed By: cortinico
Differential Revision: D64382211
fbshipit-source-id: d4fdfd51177612a64dde918cd68d6e852ef1b0e2
Summary:
Saw this while going through the remaining warnings of the project. I double checked, and i can't find any other usages left behind, so this is probably the last one
## Changelog:
[INTERNAL] [FIXED] - Switch to using the new sendString method for Websocket
Pull Request resolved: https://github.com/facebook/react-native/pull/47197
Test Plan:
yarn test:
<img width="933" alt="Screenshot 2024-10-25 at 00 55 58" src="https://github.com/user-attachments/assets/dbfebb90-4957-4fc9-8a90-153c03055ac9">
Running the tests in Xcode with `CMD+U` or the objc-test: I could not get it to pass in either the old code or the modified code. I know the test documentation said it needs a WebSocket, but it was a bit too vague , and even turning metro on did not help, so i have no idea how to test it. If anyone can guide me on that one, please let me know
Reviewed By: blakef
Differential Revision: D64934981
Pulled By: cipolleschi
fbshipit-source-id: c6f13d3da5aafe3eed8b99b98f04904fcdcc4115
Summary:
Danger seems to have a bug where it's not transpiling the import of
rnx-kit/rn-changelog-generator. This mitigates the issue to get our
project back on track.
This can be replicated locally by:
```bash
DEBUG="*" DANGER_GITHUB_API_TOKEN=$GITHUB_TOKEN yarn danger pr https://github.com/facebook/react-native/pull/47182
```
You can see it running correctly here when switching to the branch with the fix. **I'm a little concerned that this is still failing on the PR**. Thoughts?
{F1946190275}
Changelog: [internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/47192
Reviewed By: cortinico
Differential Revision: D64924466
Pulled By: blakef
fbshipit-source-id: 68df0521620809effe3a78ce842e043382ad64a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47195
When a user wants to create a Fabric Component i their app (not in a separate library) the app fails to build because:
- The custom component has to inherit from `RCTViewComponentView`
- `RCTViewComponentView` imports `ViewProps.h`
- `ViewProps.h` imports `HostPlatformViewProps.h`
- `HostPlatformViewProps.h` imports `BaseViewProps.h`
- `BaseViewProps.h` imports `YogaStylableProps.h`
which is a Yoga private header and the App has not visibility over it.
It is also not possible to fix this issue with forward declaring the `YogaStylableProps`, because `BaseViewProps` inherit from the yoga's props, so the compiler needs the full declaration of `YogaStylableProps` to work
This needs to be picked in 0.76
## Changelog
[iOS][Fixed] - Give apps access to Yoga headers
Reviewed By: blakef
Differential Revision: D64925222
fbshipit-source-id: e724076bbfb0a678948340dfab2ce609e6509533
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47176
While writing the guide for the New Architecture, we realized that we need to exclude the generation of the Cls function in the RCTThirdPartyFabricComponentsProvider for components defined in the app.
This is needed because a component that is defined in the app will have those function defined in the app project. However, the RCTThirdPartyFabricComponentsProvider is generated in Fabric, inside the Pods project.
The pod project needs to build in isolation from the app and cocoapods then link the app to the pods project. But the compilation of the pods project fails if one of the symbol needed by the pods lives in the app.
By disabling the generation of that function in th RCTThirdPartyFabricComponentsProvider, we can successfully build the app.
The downside is that the user needs to register the component manually, but this is not an issue because if they are writing a component in the app space, they have all the information tomanually register it in the AppDelegate
## Changelog
[iOS][Fixed] - Do not generate the ComponentCls function in the RCTThirdPartyFabricComponentsProvider for components deined in the app.
Reviewed By: cortinico, blakef
Differential Revision: D64739896
fbshipit-source-id: 0eca818ea0198532a611377d14a3ff4c95cb5fe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47147
By batching sync events if multiple events are dispatched during sync rendering this will reduce the number of re-renders.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D64287526
fbshipit-source-id: a5dc3b643ef1853bef9e38ce8c2f5db75e02214b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47146
This will allows us to batch sync events which leads to better performance.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D64631346
fbshipit-source-id: b82dca150c13bdb7acae6bedb392a93993273988
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47163
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces final few in libdefs.
Changelog: [internal]
Reviewed By: alexmckenley
Differential Revision: D64776942
fbshipit-source-id: 5e96c6d4fecb1b6cf539a00aecb10b9b35fc140b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47119
# Changelog:
[General] [Fixed] - Microtasks are now correctly executed after the code evaluation in Console panel of DevTools.
Fixes https://github.com/facebook/react-native/issues/46966.
`runtimeExecutor` which is propagated here, is actually being used by Hermes:
https://www.internalfb.com/code/fbsource/[cba75f2b515a]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/runtime/ReactInstance.cpp?lines=112-113
The issue was that any expression that should be evaluated as part of `Runtime.evaluate` was not going through `RuntimeScheduler`, because specified `runtimeExecutor` was not going through it as well, and it was defined prior to `RuntimeScheduler`. Because of this, `RuntimeScheduler` was not draining out the microtasks queue and basically any scheduled Microtasks were not executed, see T200616136.
With this fix, we create an executor that goes through `RuntimeScheduler`, which is using another executor that makes sure that all scheduled callbacks are only executed after `Inspector` was setup.
It is extremely messy and in the future we should untangle these circular dependencies and try to simplify the approach.
Reviewed By: rubennorte
Differential Revision: D64552372
fbshipit-source-id: 467d37c71a2eb7c940297ce90ca8d68268b1ff33
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47124
With this we start the experiment to analyze the effect of the new `BackgroundDrawable.kt` and `BorderDrawable.kt` classes. This is also essentially a kotlinification of `CSSBackgroundDrawable`
We also start using CompositeBackgroundDrawable as the source of truth for **borderRadius** and **borderInsets**
We are hoping to get neutral results and a general win for code readability.
In general when the FeatureFlag passes we should not generate a CSSBackgroundDrawable at all and just use BackgroundDrawable and BorderDrawable
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63287222
fbshipit-source-id: 7ca98290c2e152b22d09b838e5f0e1cac97b1268
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46745
**Note:** This diff still does nothing yet, it will be enabled on a diff further up the stack. This split is just to simplify reviewing
`CSSBackgroundDrawable` holds the drawing logic for both **Borders** and **Background**. This is not ideal since it results in a huge file which does 2 things.
We now have `CompositeBackgroundDrawable` which allows us to set a different drawable per "layer" on our view.
By splitting up **Border** and **Background** logic we get better modularity and it'll make it easier to implement more `backgroundImage` features without further bloating the `CSSBackgroundDrawable` file
Also, this helps with the kotlinification efforts
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62898246
fbshipit-source-id: 15d1a4ef61f0c757e648c002fc7ef26626d8e3f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46709
**Note:** This diff still does nothing yet, it will be enabled on a diff further up the stack. This split is just to simplify reviewing
`CSSBackgroundDrawable` holds the drawing logic for both **Borders** and **Background**. This is not ideal since it results in a huge file which does 2 things.
We now have `CompositeBackgroundDrawable` which allows us to set a different drawable per "layer" on our view.
By splitting up **Border** and **Background** logic we get better modularity and it'll make it easier to implement more `backgroundImage` features without further bloating the `CSSBackgroundDrawable` file
Also, this helps with the kotlinification efforts
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63137921
fbshipit-source-id: fc459beadfda1832e146e36d74c3d424a28ca905
Summary:
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`,
open `chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
In order to adopt react 19's ref-as-prop model, Flow needs to eliminate
all the places where they are treated differently.
`React.AbstractComponent` is the worst example of this, and we need to
eliminate it.
This PR eliminates them from the react repo, and only keeps the one that
has 1 argument of props.
## How did you test this change?
yarn flow
DiffTrain build for [45804af18d589fd2c181f3b020f07661c46b73ea](https://github.com/facebook/react/commit/45804af18d589fd2c181f3b020f07661c46b73ea)
Reviewed By: jbrown215
Differential Revision: D64725736
Pulled By: SamChou19815
fbshipit-source-id: c9f6f316c95d12a9ae98926faba111395b550ccf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47141
D64152004 fixed a soundness hole in Flow's checking of frozen object types (e.g. try-Flow https://fburl.com/rmct2mf6). This diff suppresses Flow errors that appear when this fix is enabled (`experimental.object_freeze_fix` flag is set).
For most of these cases the result of `Object.freeze()` is assigned to some variable typed as a mutable type. The variable is then passed to a context where its fields can be written to. Thus changing the annotation type to a readonly version would only cause more errors downstream. So, instead, these assignments are suppressed so that the choice of using Object.freeze can be revisited.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D64699992
fbshipit-source-id: 48e4376d4ed3dbda21d32cabe512e6457384994f
Summary:
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces 2 more remaining ones in react-native. Now the only remaining one is the one synced from react repo.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64722899
fbshipit-source-id: 2b2484c385fc5d6c173253f9bee66dfc736368a5
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/47143
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces most of the remaining `React.AbstractComponent` in react-native.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64701145
fbshipit-source-id: c765674fdf59812895c4fae43df97cf8b9d24f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47121
This class should be internal. I've verified this API is not used in OSS so this is technically breaking but not really affecting anyone in OSS.
Changelog:
[Android] [Breaking] - Stable API - Make AppStateModule internal
Reviewed By: Abbondanzo
Differential Revision: D64598660
fbshipit-source-id: aebc385c741e2e1f352d473db2be87d918f0ef65
Summary:
While working on https://github.com/facebook/react-native/pull/47110, I wanted to disable fabric in the `rn-tester` to test some things in Paper. I followed all the steps but ended up deleting the whole repository locally, cloning it again and explicitly installing the pods `fabric_enabled` in all steps and it didn't work. I ended up disabling the new architecture by passing `RCT_NEW_ARCH_ENABLED=0` and then it worked immediately.
Wanted to add this extra hint as it might help other contributors.
## Changelog:
[INTERNAL] [ADDED] - extra instructions to disable fabric in the `rn-tester` package
Pull Request resolved: https://github.com/facebook/react-native/pull/47127
Test Plan: Follow the instructions to disable fabric, try passing `RCT_NEW_ARCH_ENABLED=0` if `fabric_enabled = false` is not enough.
Reviewed By: cortinico
Differential Revision: D64652149
Pulled By: rshest
fbshipit-source-id: 0fc4149832a7973c57161b4fff5815414f304a3c
Summary:
Was working on something, saw that CanvasUtils has some unused imports. Figured i'd send a PR to clean up.
## Changelog:
[INTERNAL] [FIXED] - Cleanup CanvasUtils imports
Pull Request resolved: https://github.com/facebook/react-native/pull/47132
Test Plan:
Ran yarn test:
<img width="513" alt="Screenshot 2024-10-19 at 22 54 13" src="https://github.com/user-attachments/assets/6ca86852-cab5-425a-b71c-785c7d1ea95e">
Also tried running ./gradlew test, but it appears it is not having fun with my Node version (18.20.3), so `createBundleHermesReleaseJsAndAssets` randomly fails, to be investigated why:
<img width="1515" alt="Screenshot 2024-10-19 at 22 56 02" src="https://github.com/user-attachments/assets/f860cdc5-4f42-4d54-9497-7eaa028b6bc6">
Reviewed By: NickGerleman
Differential Revision: D64663918
Pulled By: cortinico
fbshipit-source-id: a681d6ee76dfcbc56889e76da6cf8ea11907bdf2
Summary:
This PR adds support for `display: contents` style by effectively skipping nodes with `display: contents` set during layout.
This required changes in the logic related to children traversal - before this PR a node would be always laid out in the context of its direct parent. After this PR that assumption is no longer true - `display: contents` allows nodes to be skipped, i.e.:
```html
<div id="node1">
<div id="node2" style="display: contents;">
<div id="node3" />
</div>
</div>
```
`node3` will be laid out as if it were a child of `node1`.
Because of this, iterating over direct children of a node is no longer correct to achieve the correct layout. This PR introduces `LayoutableChildren::Iterator` which can traverse the subtree of a given node in a way that nodes with `display: contents` are replaced with their concrete children.
A tree like this:
```mermaid
flowchart TD
A((A))
B((B))
C((C))
D((D))
E((E))
F((F))
G((G))
H((H))
I((I))
J((J))
A --> B
A --> C
B --> D
B --> E
C --> F
D --> G
F --> H
G --> I
H --> J
style B fill:https://github.com/facebook/react-native/issues/050
style C fill:https://github.com/facebook/react-native/issues/050
style D fill:https://github.com/facebook/react-native/issues/050
style H fill:https://github.com/facebook/react-native/issues/050
style I fill:https://github.com/facebook/react-native/issues/050
```
would be laid out as if the green nodes (ones with `display: contents`) did not exist. It also changes the logic where children were accessed by index to use the iterator instead as random access would be non-trivial to implement and it's not really necessary - the iteration was always sequential and indices were only used as boundaries.
There's one place where knowledge of layoutable children is required to calculate the gap. An optimization for this is for a node to keep a counter of how many `display: contents` nodes are its children. If there are none, a short path of just returning the size of the children vector can be taken, otherwise it needs to iterate over layoutable children and count them, since the structure may be complex.
One more major change this PR introduces is `cleanupContentsNodesRecursively`. Since nodes with `display: contents` would be entirely skipped during the layout pass, they would keep previous metrics, would be kept as dirty, and, in the case of nested `contents` nodes, would not be cloned, breaking `doesOwn` relation. All of this is handled in the new method which clones `contents` nodes recursively, sets empty layout, and marks them as clean and having a new layout so that it can be used on the React Native side.
Relies on https://github.com/facebook/yoga/pull/1725
X-link: https://github.com/facebook/yoga/pull/1726
This PR adds a few things over the corresponding one in Yoga:
- new value in the `DisplayType` enum - `Contents`
- new `ShadowNodeTrait` - `ForceFlattenView`, that forces the node not to form a host view
- updates TS types to include `display: contents`
- aliases `display: contents` to `display: none` on the old architecture
## Changelog:
[GENERAL] [ADDED] - Added support for `display: contents`
Pull Request resolved: https://github.com/facebook/react-native/pull/46584
Test Plan:
<details>
<summary>So far I've been testing on relatively simple snippets like this one and on entirety of RNTester by inserting views with `display: contents` in random places and seeing if anything breaks.</summary>
```jsx
import React from 'react';
import { Button, Pressable, SafeAreaView, ScrollView, TextInput, View, Text } from 'react-native';
export default function App() {
const [toggle, setToggle] = React.useState(false);
return (
<View style={{flex: 1, paddingTop: 100}}>
<SafeAreaView style={{width: '100%', height: 200}}>
<Pressable style={{width: 100, height: 100, backgroundColor: 'black'}} onPress={() => setToggle(!toggle)}>
<ScrollView />
</Pressable>
<View style={{display: 'flex', flexDirection: 'row', flex: 1, backgroundColor: 'magenta'}}>
<SafeAreaView style={{
// display: 'contents',
flex: 1,
}}>
<View style={{
display: 'contents',
width: '100%',
height: 200,
}}>
<View style={{
display: 'contents',
flex: 1,
}}>
{ toggle && <View style={{flex: 1, backgroundColor: 'yellow'}} /> }
<View style={{flex: 1, backgroundColor: 'blue'}} />
<View style={{flex: 1, backgroundColor: 'cyan'}} />
</View>
</View>
</SafeAreaView>
</View>
{/* <View style={{width: 100, height: 100, backgroundColor: 'magenta', display: 'flex'}} /> */}
<TextInput style={{width: 200, height: 100, backgroundColor: 'red', display: 'flex'}}>
<Text style={{color: 'white'}}>Hello</Text>
<Text style={{color: 'green'}}>World</Text>
</TextInput>
</SafeAreaView>
</View>
);
}
```
</details>
Reviewed By: joevilches
Differential Revision: D64584476
Pulled By: NickGerleman
fbshipit-source-id: bec77b5087ff95f0980cf02274fbb2c8581eb3c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47035
This PR adds support for `display: contents` style by effectively skipping nodes with `display: contents` set during layout.
This required changes in the logic related to children traversal - before this PR a node would be always laid out in the context of its direct parent. After this PR that assumption is no longer true - `display: contents` allows nodes to be skipped, i.e.:
```html
<div id="node1">
<div id="node2" style="display: contents;">
<div id="node3" />
</div>
</div>
```
`node3` will be laid out as if it were a child of `node1`.
Because of this, iterating over direct children of a node is no longer correct to achieve the correct layout. This PR introduces `LayoutableChildren::Iterator` which can traverse the subtree of a given node in a way that nodes with `display: contents` are replaced with their concrete children.
A tree like this:
```mermaid
flowchart TD
A((A))
B((B))
C((C))
D((D))
E((E))
F((F))
G((G))
H((H))
I((I))
J((J))
A --> B
A --> C
B --> D
B --> E
C --> F
D --> G
F --> H
G --> I
H --> J
style B fill:https://github.com/facebook/yoga/issues/050
style C fill:https://github.com/facebook/yoga/issues/050
style D fill:https://github.com/facebook/yoga/issues/050
style H fill:https://github.com/facebook/yoga/issues/050
style I fill:https://github.com/facebook/yoga/issues/050
```
would be laid out as if the green nodes (ones with `display: contents`) did not exist. It also changes the logic where children were accessed by index to use the iterator instead as random access would be non-trivial to implement and it's not really necessary - the iteration was always sequential and indices were only used as boundaries.
There's one place where knowledge of layoutable children is required to calculate the gap. An optimization for this is for a node to keep a counter of how many `display: contents` nodes are its children. If there are none, a short path of just returning the size of the children vector can be taken, otherwise it needs to iterate over layoutable children and count them, since the structure may be complex.
One more major change this PR introduces is `cleanupContentsNodesRecursively`. Since nodes with `display: contents` would be entirely skipped during the layout pass, they would keep previous metrics, would be kept as dirty, and, in the case of nested `contents` nodes, would not be cloned, breaking `doesOwn` relation. All of this is handled in the new method which clones `contents` nodes recursively, sets empty layout, and marks them as clean and having a new layout so that it can be used on the React Native side.
Relies on https://github.com/facebook/yoga/pull/1725
Changelog: [Internal]
X-link: https://github.com/facebook/yoga/pull/1726
Test Plan: Added tests for `display: contents` based on existing tests for `display: none` and ensured that all the tests were passing.
Reviewed By: joevilches
Differential Revision: D64404340
Pulled By: NickGerleman
fbshipit-source-id: f6f6e9a6fad82873f18c8a0ead58aad897df5d09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47125
Original commit changeset: 9f05a461d178
Original Phabricator Diff: D64238887
Changelog: [Internal]
NOTE: while this seems to work on IGVR it breaks on the two use cases highlighted in D64339251, backing out the diff while trying to find out a solution that works on all cases!
Reviewed By: Abbondanzo
Differential Revision: D64611594
fbshipit-source-id: b43353b17448c181a76b2af09968cf0e4934c53c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47126
This will be used to validate the fix to `maintainVisibleContentPosition` for the two major use cases when the FlatList resizes:
* when the items have fixed size
* when the items scale with the size of the list
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D64339251
fbshipit-source-id: d0ee8d73cd9e6527a7ce0950e8f3941337b70474
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47120
Fixes no-op behaviour of the "Open DevTools" Dev Menu item (bug on `main` introduced with D63329456).
This was caused by a change to the `description` field contents in our CDP `/json/list` response, when under Fusebox. In the `/open-debugger` call from the Dev Menu, we were still using the older `appId` param.
This did not affect `j` to debug, which uses the `target` param.
{F1937186832}
Changes:
In short: Matching against the `description` string is now fully eliminated for modern debugger targets.
- Update native Dev Menu implementation to omit `appId` parameter (`device` param alone is sufficient and fully precise on these platforms).
- Update `/open-debugger` implementation to ignore the `appId` parameter for modern targets, and document this in the `dev-middleware` README.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D64597581
fbshipit-source-id: 46f536e7d0a4ececab0d52f4c0704e8698466cd0
Ramanpreet Nara
Samuel Susla
David Vacca
Parsa Nasirimehr
Blake Friedman
Riccardo Cipolleschi
Sunny Luo
Thomas Nardone
Alan Lee
Sam Zhou
Cody Pizzaia
Phillip Pan
Liron Yahdav
Ruslan Lesiutin
Nick Gerleman
Jorge Cabiedes Acosta
SamChou19815 (Meta Employee)
Panos Vekris
Eli White
Nicola Corti
Mateo Guzmán
Jakub Piasecki
Fabrizio Cucci
Alex Hunt