Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42396
Cmmunity reported [#42120](https://github.com/facebook/react-native/issues/42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.
Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.
This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.
## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge
Reviewed By: RSNara
Differential Revision: D52912604
fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42619
This is a workaround to prepare for the next diff in the stack and make sure that the modal works correctly
## Changelog
[iOS][Changed] - Add the for the dismissal snapshot only when we need it.
Reviewed By: sammy-SC
Differential Revision: D53003657
fbshipit-source-id: 6d6cc85946b1beb8e784e08a650d1247cf780228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42587
Changelog: [Internal]
* Introduces the Target Delegate and Target Controller concepts (see `CONCEPTS.md`).
* Introduces the `PageTargetDelegate` interface and `PageTargetController` class (see doc comments).
* Uses the above infra to implement support for the `Page.reload` CDP command. Each integration provides its own `PageTargetDelegate` that knows how to trigger a reload in a platform- and architecture-specific way.
* iOS Bridge/Bridgeless and `PageTargetTest` are the only integrations that exist as of this diff, and are all updated here; Android will follow later.
NOTE: `RCTBridge` = iOS Bridge, `RCTHost` = iOS Bridgeless.
## Object lifetimes
`PageAgent` holds a raw `PageTargetController&` reference to a member of `PageTarget`, through which it gets access to that target's `PageTargetDelegate&` (another raw reference).
Here's what makes this safe:
1. **`PageTargetDelegate` outlives `PageTarget`** - this is the responsibility of the platform integration ( = the code that instantiates `PageTarget`).
2. **`PageTarget` outlives its Sessions and Agents** - this is `PageTarget`'s "moral" responsibility, even though it doesn't own its Sessions outright (`InspectorPackagerConnection` does). We add an assertion in `PageTarget`'s destructor to catch violations, and document that the integrator must call `getInspectorInstance().removePage` (which terminates all remaining sessions) before destroying the corresponding `PageTarget`.
NOTE: In upcoming diffs we'll use the new Target→Session references, currently used only for the assertion in (2), to power actual functionality (e.g. dispatching CDP events to the frontend when some imperative method is called on `PageTarget`).
## Thread safety
`PageTargetDelegate::onReload` is guaranteed to be called synchronously on the thread where messages are dispatched to `PageTargetSession`, which on iOS is the main (UI) thread.
Reviewed By: huntie
Differential Revision: D51164125
fbshipit-source-id: 4c3eeb81a8df9677c173588eb5acfd686722c3c9
Summary:
Clean up the function naming in `TextMeasureCache.h`. One name was clearly a human mistake. Make the naming consistent.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## 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] [CHANGE] - Clean up the function naming in `TextMeasureCache.h`
Pull Request resolved: https://github.com/facebook/react-native/pull/42598
Reviewed By: NickGerleman
Differential Revision: D52960435
Pulled By: sammy-SC
fbshipit-source-id: 01327610446933972e8dc87e1b6e2950b7c706d2
Summary:
### The problem
1. We have a library that's supported on iOS but doesn't have support for visionOS.
2. We run pod install
3. Codegen runs and generates Code for this library and tries to reference library class in `RCTThirdPartyFabricComponentsProvider`
4. Example:
```objc
Class<RCTComponentViewProtocol> RNCSafeAreaProviderCls(void) __attribute__((used)); // 0
```
This is an issue because the library files are not linked for visionOS platform (because code is linked only for iOS due to pod supporting only iOS).
### Solution
Make codegen take Apple OOT platforms into account by adding compiler macros if the given platform doesn't explicitly support this platform in the native package's podspec file.
Example generated output for library supporting only `ios` and `visionos` in podspec:
I used compiler conditionals because not every platform works the same, and if in the future let's say react-native-visionos were merged upstream compiler conditionals would still work.
Also tvOS uses Xcode targets to differentiate which platform it builds so conditionally adding things to the generated file wouldn't work.
## Changelog:
[IOS] [ADDED] - make codegen take OOT Apple platforms into account
Pull Request resolved: https://github.com/facebook/react-native/pull/42047
Test Plan:
1. Generate a sample app with a template
5. Add third-party library (In my case it was https://github.com/callstack/react-native-slider)
6. Check if generated codegen code includes compiler macros
Reviewed By: cipolleschi
Differential Revision: D52656076
Pulled By: dmytrorykun
fbshipit-source-id: c827f358997c70a3c49f80c55915c28bdab9b97f
Summary:
Extract fragment conversions to separate functions to make refactoring easier and simplify reasoning about the code.
This code is being modified later.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## 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] [CHANGE] - Extract fragment conversions to separate functions
Pull Request resolved: https://github.com/facebook/react-native/pull/42597
Reviewed By: NickGerleman
Differential Revision: D52960655
Pulled By: robhogan
fbshipit-source-id: 0df62b9980c06a1c2fc113d645ba8b6b668fa394
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42411
X-link: https://github.com/facebook/yoga/pull/1562
I added a small regression D52605596, where negative border would not be correctly floored. This fixes that, and starts adding tests specifically targeting the computed style API, now decoupled from the yoga node.
Reviewed By: joevilches
Differential Revision: D52930827
fbshipit-source-id: e165dade705a8de54c92d65f3664c9081137788c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42410
Changelog: [Internal]
Properly compiling these files out so we don't need to pull in SocketRocket to startup
Long term, we need to lift DevSupport and Inspector directories out of ReactInternal target
Reviewed By: fkgozali
Differential Revision: D52890707
fbshipit-source-id: efe59092d8f5487ab3f62ffb4ebd2b8aa58399fe
Summary:
X-link: https://github.com/facebook/yoga/pull/1561
Back when I introduced the inline functions that would get the edge according to the writing direction I swapped some instances of `setLayoutPosition` which wrote to the flexStart edge erroneously. We should basically never read from some inline style and write to the flex edge. This changes them all to use the flex values.
Reviewed By: NickGerleman
Differential Revision: D52921401
fbshipit-source-id: 92b74d652018596134c91827806272ed7418ef6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42400
Changelog: [Internal]
TSIA - iOS counterpart of D52040149 on Android.
The overarching principle is that nothing outside of an Agent should be doing anything with the CDP message stream. Here we have a case of `RCTInspectorDevServerHelper` basically impersonating the CDP frontend in order to paper over an apparent lifetime management bug in the old backend; this gets in the way of implementing reloads natively so we disable it under the new backend.
NOTE: I'm gating out both the call site in `RCTBridge` (to signal intent) *and* the actual body of `disableDebugger` (in case any out-of-tree code happens to be using this method).
Reviewed By: voideanvalue
Differential Revision: D50967799
fbshipit-source-id: 759718bf155b8b16c7db54ac2d2507bc71c93436
Summary:
This change removes Content-Length header from proxy inspector response.
The presence of this header was resulting in the response being cropped under some circumstances because of erroneously calculated length.
The `Content-Length` header value represents the number of bytes in the response. In the code, `string.length` was used to calculate that value, but in JavaScript it gives the number of characters in a string instead of its size in bytes. Specifically, if there are some UTF characters in the string that occupy more than byte, there would be a mismatch in this size. This mismatch resulted in the response being cropped.
The easiest way to reproduce this problem is to set the simulator name to contain a two-byte UTF character.
This change works according to the HTTP spec, which states that when Content-Length is not present, the end of the response stream indicates the end of the response. Since in the code `response.end(data)` is use, it terminates the stream and hence there is no need to provide the length in the header.
## Changelog:
[GENERAL] [FIXED] - fix issue with debugger not working when device name contain two-byte UTF characters
Pull Request resolved: https://github.com/facebook/react-native/pull/42590
Test Plan:
1. Change your iOS simulator name to contain some two-byte UTF character (for example this one: "–")
2. Run metro and connect your app with it
3. Go to http://localhost:8081/json/list in your browser – see the response being marked invalid as it is cropped
4. Apply the change and see that the resulting JSON in the response is now correct
5. Open debugger workflow to confirm it sees the connected device
Reviewed By: robhogan
Differential Revision: D52958725
Pulled By: motiz88
fbshipit-source-id: 92c32893cbbf8552237585d824e4a44737fa3968
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42388
This was our last call site still using the legacy `dispatch` API.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52906894
fbshipit-source-id: b1c838ee695ce4c60aaed409e7dc46a0dd3f6c2e
Summary:
Over in React Native macOS land, I opened https://github.com/microsoft/react-native-macos/pull/2030 to update our mono repo to use Yarn 4. As a side effect, all the `package.json` files are formatted as a side effect of running `yarn install`. So that React Native macOS doesn't maintain this diff (and because they should only be good / no harm), let's upstream the formatting changes.
## Changelog:
[INTERNAL] [CHANGED] - Format package.json files in the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/42256
Test Plan: This change should be a no-op, CI should pass.
Reviewed By: cortinico
Differential Revision: D52727623
Pulled By: huntie
fbshipit-source-id: 67862b16d576b0903abd91e016d7add4c19853dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42394
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridge behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridge.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Reviewed By: huntie
Differential Revision: D50951138
fbshipit-source-id: 8c5ad9207e73265595884380c91e38f8d0ead84d
Summary:
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridgeless behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridgeless.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Pull Request resolved: https://github.com/facebook/react-native/pull/42393
Test Plan:
1. `js1 run`
2. Enable the modern CDP backend by grafting D52844391
3. Enable Bridgeless in RNTester by grafting D52910646
4. `buck2 install rntester-ios`
5. Dev Menu -> Open Debugger
6. Observe console message self-identifying the backend + iOS Bridgeless
7. Observe that the debugger stays connected when the app is reloaded (albeit without doing anything very interesting just yet)
{F1329876835}
Reviewed By: huntie
Differential Revision: D50936931
Pulled By: motiz88
fbshipit-source-id: ff8f919d0370266aea2916da349520bc76d690ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42294
This changes enables the Fabric Intrerop Layer automatically for all the users.
Practically I'm removing the fallback `ComponentDescriptor` inside the `ComponentDescriptorRegistry` so that if a component hasn't been automatically registered by a user, instead of showing the UnimplementedView, it loads a `UnstableLegacyViewManagerAutomaticComponentDescriptor`.
This ComponentDescriptor is built starting from the legacy component name, and responds with correct `ComponentName` and `ComponentHandle` (similarly to the `UnstableLegacyViewManagerInteropComponentDescriptor` but without using C++ templates).
Changelog:
[Internal] [Changed] - Fabric Automatic Interop for Android
Reviewed By: sammy-SC
Differential Revision: D52663244
fbshipit-source-id: f466486c638bb1362ef59128cd69bb9731bb9739
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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42386
The new DOM APIs are completely private at the moment, so they make them a good candidate to test the new directory structure (and make sure everything works correctly in CI, etc.). This moves those files to `src/private/dom`.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875998
fbshipit-source-id: c6c96eedcc54d47e3afff98fa2d912f9d83f3460
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42385
This adds support for having JS files in a `src` directory within the `react-native` package. The plan is to have 2 subdirectories there:
* `react-native/src/private` for private modules, with any nested directories (e.g.: `react-native/src/private/dom/nodes/ReadOnlyNode.js`).
* `react-native/src/public` for public modules, without nested directories. The plan is that the individual modules created in this directory will be public through the index module or directly via something like `react-native/View` (mapped to `react-native/src/public/View`, or a `dist` directory in the published npm package—details TBD).
The enforcement of private modules being inaccessible from outside the `react-native` package will be added soon by huntie.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875999
fbshipit-source-id: 914ed806f2cb86857e2cb7b760292c2190b5b14e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42585
Just a minor bump of AGP to 8.2.1
Changelog:
[Internal] [Changed] - Bump AGP to 8.2.1
Reviewed By: NickGerleman
Differential Revision: D52912324
fbshipit-source-id: 2856861f2ccedb3470a0fa548a31dd36252924c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42131
X-link: https://github.com/facebook/yoga/pull/1534
Now that the storage method is a hidden implementation detail, this changes the underlying data structure used to store styles, from `CompactValue` (a customized 32-bit float with tag bits), to `StyleValuePool`.
This new structure operates on 16-bit handles, and a shared small buffer. The vast majority of real-world values can be stored directly in the handle, but we allow arbitrary 32 bit (and soon 64-bit) values to be stored, where the handle then becomes an index into the styles buffer.
This results in a real-world memory usage win, while also letting us store the 64-bit values we are wanting to use for math function support (compared to doubling the storage requirements).
This does seem to make style reads slower, which due to their heavy frequency, does have a performance impact observable by synthetics. In an example laying out a tree of 10,000 nodes, we originally read from `StyleValuePool` 2.4 million times.
This originally resulted in a ~10% regression, but when combined with the changes in the last diff, most style reads become simple bitwise operations on the handle, and we are actually 14% faster than before.
| | Before | After | Δ |
| `sizeof(yoga::Style)` | 208B | 144B | -64B/-31% |
| `sizeof(yoga::Node)` | 640B | 576B | -64B/-10% |
| `sizeof(YogaLayoutableShadowNode) ` | 920B | 856B | -64B/-7% |
| `sizeof(YogaLayoutableShadowNode) + sizeof(YogaStylableProps)` | 1296B | 1168B | -128B/-10% |
| `sizeof(ViewShadowNode)` | 920B | 856B | -64B/-7% |
| `sizeof(ViewShadowNode) + sizeof(ViewShadowNodeProps)` | 2000B | 1872B | -128B/-6% |
| "Huge nested layout" microbenchmark (M1 Ultra) | 11.5ms | 9.9ms | -1.6ms/-14% |
| Quest Store C++ heap usage (avg over 10 runs) | 86.2MB | 84.9MB | -1.3MB/-1.5% |
Reviewed By: joevilches
Differential Revision: D52223122
fbshipit-source-id: 990f4b7e991e8e22d198ce20f7da66d9c6ba637b
Summary:
A first step in my work on https://github.com/react-native-community/discussions-and-proposals/issues/695
De-duplicate the code for creating `Spannable` on Android. I'm planning to add quite serious new features to this module. This would be really hard with the current level of code duplication.
## Changelog:
[INTERNAL] [CHANGED] - De-duplicate building `Spannable` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/39630
Test Plan: I tried to ensure that the refactored code is relatively easy to prove to be equivalent to the original duplicated one, but there's always a risk of a human mistake in this process. So far, I have been testing this by ensuring that nothing broke in the `Text` example section in RNTester.
Reviewed By: mdvacca
Differential Revision: D51016244
Pulled By: NickGerleman
fbshipit-source-id: e9f873c01b2af0685c7b0943aebea170c997d22e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42399
Mark CallInvokerHolder APIs as FrameworkAPI only, these APIs are meant to be used only for partner frameworks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D52913739
fbshipit-source-id: 5a2c8be629e90a33e0cfb66b28e0171c71f5940d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42387
Changelog: [Internal]
Documents that it's legal for a Page's connection function to return null, and adds new logic to `InspectorPackagerConnection` (NOTE: to the C++ implementation *only*) to handle this case without crashing.
The legacy RN CDP backend (`ConnectionDemux`) has a case similar to this that causes crashes depending on the timing of connection requests.
Reviewed By: cortinico
Differential Revision: D52905490
fbshipit-source-id: 2102adc859d1509647a31f92737a1e164781fadf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42384
Changelog: [Internal]
Similar to D52894171, adds a console log message identifying the specific CDP backend integration, based on an optional `SessionMetadata` object passed to `PageTarget::connect()`. This is helpful during development+rollout as we will have 4+ such call sites (iOS/Android, Bridge/Bridgeless).
Reviewed By: huntie
Differential Revision: D52905488
fbshipit-source-id: d26aae1d07c2c42965498a81f03d826de98fa222
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42383
Changelog: [Internal]
During development / experimental rollout of the modern CDP backend, it can be helpful to have a user-visible message that makes it clear that the new backend is in use. Here, we add one using the [`Log.entryAdded`](https://chromedevtools.github.io/devtools-protocol/tot/Log/#type-LogEntry) CDP event. We also add some styling using [ANSI escape sequences](https://developer.chrome.com/docs/devtools/console/format-style#style-ansi) to make the message stand out from normal application logs.
We could have used [`Runtime.consoleAPICalled`](https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#event-consoleAPICalled) instead, but:
1. `Runtime.consoleAPICalled` requires an `executionContextId` which is not available at the `Page` level (it is a concept that's managed closer to the instance/VM), and it's slightly cleaner if we don't have to send a fake context ID.
2. It's slightly easier to follow the CDP dispatching logic / grep for relevant code if we use `Log` for "system logs" (from the Page) and reserve `Runtime` for real application logs from the instance/VM.
NOTE: We'll probably want to remove this before the stable release.
Reviewed By: huntie
Differential Revision: D52894171
fbshipit-source-id: 3208e01f2ee31acef2e8cd58767f40ad724c9a39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42397
Changelog: [Internal]
Adds a stub `PageTarget` class to serve as the entry point to the modern CDP backend in React Native.
The primary method exposed by `PageTarget` is `connect()` which is designed to fit directly as a connection callback passed to `InspectorPackagerConnection::addPage()`. This constructs a `PageTargetSession` containing a `PageAgent` where the actual CDP message handling/routing will occur. For now, `PageAgent` implements no CDP methods, and always responds with a "not implemented" error.
Basic unit tests are included, though we might want to migrate to a more integration-style test suite (with fewer mocks and real bindings to RN) once we've implemented more of the protocol.
## What is a Page
In Chrome's implementation of CDP, a Page represents a single browser tab. A Chrome DevTools session connects to one Page at a time (though it can potentially inspect multiple JavaScript contexts owned by that Page, such as those found in frames and workers).
In our system, a Page will correspond 1:1 to React Native's concept of a *Host* (implemented as `RCTHost`, `RCTBridge`, `ReactHostImpl` or `ReactInstanceManager`, depending on the platform). In all cases, the Host is the object that has a stable identity across reloads, and manages the lifetime of an *Instance* where the JSVM and other application state lives. There can be multiple Hosts in a React Native process, though this is somewhat unusual; those would be treated as independent "tabs" from the perspective of the debugger.
NOTE: The concepts of Target, Session and Agent are new (to this codebase) and are *broadly* inspired by the [corresponding Chromium / V8 concepts](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/public/devtools_protocol/#Agents_Targets-and-Sessions), though some details differ.
## Next steps
Each core platform implementation in React Native (iOS Bridgeless, iOS Bridge, Android Bridgeless, Android Bridge), as well as out-of-tree platforms that want to support the new debugger, will need to create and register a `PageTarget` instance. We'll do this piecemeal in subsequent diffs.
We'll also gradually add APIs and logic to `PageTarget` / `PageAgent` to allow us to implement some "interesting" CDP methods - some of them directly (e.g. handling reload commands) and others by dispatching to nested agents (e.g. a JS debugging agent powered by Hermes).
Reviewed By: huntie
Differential Revision: D50936932
fbshipit-source-id: ebe5856d7badb361d4971dd9aabeb9982f8aed1b
Summary:
Recently inside React Native Community CLI we added bumping Yarn version inside `init` command, more information here: https://github.com/react-native-community/cli/pull/2134. In this Pull Request I added required rules in `.gitignore` for new projects created.
## Changelog:
[GENERAL] [ADDED] - Add Yarn files to `.gitignore` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/42313
Test Plan:
1. Follow [Contributing guide](https://github.com/react-native-community/cli/blob/main/CONTRIBUTING.md) from React Native Community CLI repository to setup locally newest version of CLI.
2. Run this command:
```sh
node /path/to/react-native-cli/packages/cli/build/bin.js init --template path/to/template
```
3. Appropriate should be ignored.
Reviewed By: NickGerleman
Differential Revision: D52907962
Pulled By: cortinico
fbshipit-source-id: f12dce8836e7e94257f8c690434b11227aa46446
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42254
X-link: https://github.com/facebook/yoga/pull/1550
This change aims to simplify how we resolve edges. This operation happens many, many times, and has gotten complex and slow when paired with StyleValuePool.
This starts reshaping so that `yoga::Style` can resolve a style prop for a given edge. This is closer to the ideal computed style API to avoid recalcing this so many times, but doesn't address that.
This relies on removing the errata related to row-reverse, and cleans up the removal started in the last change.
This has no measurable perf effect under CompactValue, but has a >10% uplift in perf when using StyleValueHandle, where we can trivially check if a handle points to a defined value without resolving it, but only within `yoga::Style` since we don't expose the handle outside of it.
More quantifiably, we go from 2.35 million StyleValuePool reads to 993k. The rest are checks on the handle.
Reviewed By: joevilches
Differential Revision: D52605596
fbshipit-source-id: 0b366963a899e376f99ce3d75cd5f14a25d60cec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42314
X-link: https://github.com/facebook/yoga/pull/1555
The next diff moves a bunch of methods to `yoga::Style`. This renames the function to be a tad bit shorter, for more readable callsites. It also makes it more consistent with style property getters.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52803393
fbshipit-source-id: 557df34a9f0fb0ee42ad23b1fda99c1e0eb1d4e3
Summary:
This removes the 4 ineffective and redundant entries from the `exclude` list in `tsconfig.json` (`typescript-config` package).
These entries have no effect as they are relative to the typescript-config package. Explained in detail here: https://github.com/tsconfig/bases/issues/207
A newly generated RN app shows this config:
```
$ yarn tsc --showConfig | grep -A 5 exclude
"exclude": [
"node_modules/tsconfig/react-native/node_modules",
"node_modules/tsconfig/react-native/babel.config.js",
"node_modules/tsconfig/react-native/metro.config.js",
"node_modules/tsconfig/react-native/jest.config.js"
]
```
Clearly, none of these files exist, therefore to remove ambiguity and reduce the complexity of the config, they should be removed.
## Changelog:
[GENERAL] [REMOVED] - Remove ineffective excludes from typescript-config
Pull Request resolved: https://github.com/facebook/react-native/pull/42375
Test Plan:
- Create new RN app (`npx react-native init`), install dependencies, run `yarn tsc`
- It works
- Recreate config, but _without_ the `exclude` section
- Everything works exactly the same
Reviewed By: huntie
Differential Revision: D52904713
Pulled By: NickGerleman
fbshipit-source-id: d1d6f65b164053f9a1e611022178ced032a38aef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42390
Changelog: [Internal]
Add an optional mechanism for inspector pages to be registered with the "modern" or "legacy" type (defaulting to legacy). This is aligned with the inspector-proxy implementation of the `type` property in D50967795.
NOTE: This mechanism is experimental, only takes effect if `InspectorPackagerConnection.cpp` is in use, and will likely evolve before the RN 0.74 branch cut.
Reviewed By: huntie
Differential Revision: D50967794
fbshipit-source-id: e7521267dfc0b0811c4d369e63f4f1756ce22d60
Luna Wei
Ingrid Wang
Riccardo Cipolleschi
Moti Zilberman
Jakub Trzebiatowski
Oskar Kwaśniewski
Nick Gerleman
Phillip Pan
Joe Vilches
Xin Chen
Alex Hunt
Christoph Purrer
Rubén Norte
Krzysztof Magiera
Pieter De Baets
Saad Najmi
Himanshi Goyal
LIM Albert
Moti Zilberman
Nicola Corti
Erica Klein
David Vacca
szymonrybczak
Fabrizio Cucci
Frieder Bluemle