Summary:
Changelog: [General][Added] Enable setNativeProps in animations in the New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/42603
Enabling setNativeProps in animations on by default.
Reviewed By: mdvacca
Differential Revision: D52962882
fbshipit-source-id: 67921c8e36e97b7b1315dfa0d5f3bd708ccb0079
Summary:
`TextLayoutUtils`: Use named arguments to ensure same-type arguments (like `start`/`end`) are not confused
This is a minor readability follow-up to https://github.com/facebook/react-native/pull/39630.
## 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] [CHANGED] - Increase the `TextLayoutUtils` readability slightly
Pull Request resolved: https://github.com/facebook/react-native/pull/42593
Reviewed By: NickGerleman
Differential Revision: D53028402
Pulled By: mdvacca
fbshipit-source-id: 39e99ba70b93eecfc51bda19d30a5b1977cfe406
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42638
Enables these modules to be covered by `public-api-test`.
- Standardise as CommonJS modules, fixing compatibility with [`flow-api-translator`](https://www.npmjs.com/package/flow-api-translator).
- Use explicit object type in generated file template.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52963967
fbshipit-source-id: c9f3e35f70859c1b99b7297228ee2498f91d9041
Summary:
With the current ways metro location is determined, when we want to use a different metro port this requires app to be rebuild as the port and location are stored in resource file that gets compiled to R.class. The only way to avoid app rebuild due to a port change is to use shared preferences that can be accessed from dev menu, where metro URL can be specified. However, due to a separate code-paths for retrieving bundle location and for `/inspector/device` calls, the setting only applies to the former. As a consequence, you can change metro URL in the shared preferences, but debugging would only work if you use the default port or you rebuild the app with the correct port number.
This PR removes the separate code-path for retrieving inspector URL including all the dependencies scattered across different files including the gradle plugin. We then replace calls to `PackagerConnectionSettings.getInspectorServerHost` with `PackagerConnectionSettings.getDebugServerHost` which respects the shared preferences and other possible ways of configuring the port.
I decided to remove the separate inspector URL code path, as the resource value for inspector port added in https://github.com/facebook/react-native/issues/23616 was never functioning properly due to a bug. In the said PR introduced a bug in [AndroidInfoHelpers.java](https://github.com/facebook/react-native/blob/a13d51ff1c38ea85e59f4215563c0dd05452f670/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/systeminfo/AndroidInfoHelpers.java#L77) where `react_native_dev_server_port` was used instead `react_native_inspector_proxy_port`. As a result the added resource value was never read.
This can be potentially a breaking change as I'm removing some public methods. However I think it is unlikely anyone relied on said methods. As a part of this PR I'm also changing occurences of removed methods from ReactAndroid.api – I don't know how to test those changes since I don't understand how this file is used as it doesn't have any references in public code.
## Changelog:
[ANDROID] [FIXED] - Make Android respect metro location from shared preferences for the debugger workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/42617
Test Plan:
1. Run android app on emulator using default port
2. Check the debugger works when using "Open Debugger" option from dev menu
3. Restart metro with custom port (`--port 9090`) while keeping the app running
4. Open dev menu, click "Settings" then "Debug server host & port", put "10.0.2.2:9090" there
5. Reload the app
6. Before this change things like hot reload would continue to work while "Open Debugger" option would do nothing
7. After this change both reloading and debugging will work
Important: I haven't tested changes made to ReactAndroid.api as I don't know what this files is used for with no references in the codebase.
Reviewed By: cortinico
Differential Revision: D53010023
Pulled By: huntie
fbshipit-source-id: cc8b9c5c7e834ec9ea02b1ed5acf94f04f7b7116
Summary:
since https://github.com/facebook/react-native/commit/32dab7a63fd0795c3aaefa766aa9f818428ed2de, `DoubleConversion` is now added as an implicit dependency for 3rd party module and it breaks swift integration. this pr tries to add the `DEFINES_MODULE` to DoubleConversion.
## Changelog:
[IOS] [FIXED] - Fixed `DoubleConversion` build error from Swift integration
Pull Request resolved: https://github.com/facebook/react-native/pull/42591
Test Plan:
i'll need to test this on expo latest and react-native nightly build
```sh
# pull latest expo repo and get template tarball
$ git clone --depth 1 https://github.com/expo/expo.git
$ cd expo
$ yarn install
$ cd templates/expo-template-bare-minimum
$ npx pack --pack-destination ../../
# now create an expo app
$ yarn create expo -t blank@sdk-50 sdk50
$ cd sdk50
$ yarn add react-native@nightly
$ jq '.expo.runtimeVersion = { "policy": "appVersion" }' app.json > app.json.tmp && mv app.json.tmp app.json
$ npx expo prebuild -p ios --template /path/to/expo/expo-template-bare-minimum-50.0.17.tgz
$ cd ios
$ pod install
```
then it will show the error message:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `ExpoModulesCore` depends upon `DoubleConversion`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
Reviewed By: cortinico
Differential Revision: D53048352
Pulled By: cipolleschi
fbshipit-source-id: b1e27d3d26e8543a4cb2e8062c93c68543a051c5
Summary:
This PR removes the `apply_ats_config` function of ReactNativePodsUtils that was used inside `react_native_post_install` because it was preventing users from configuring `NSAllowsArbitraryLoads` to true in their projects, especially when building in CI as the plist file would be reset after running pod install.
## Changelog:
[IOS] [CHANGED] - Remove ATS config patch from react_native_post_install
Pull Request resolved: https://github.com/facebook/react-native/pull/42637
Test Plan: Edit `Info.plist`, run `pod install` and check if changes have not been overwritten
Reviewed By: cortinico
Differential Revision: D53048299
Pulled By: cipolleschi
fbshipit-source-id: 8dc335fae2e05a62daf931a50fa3f7a314e76a2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42639
When I reverted part of the deprecation of `RCT_NEW_ARCH_ENABLED`, I forget a little bit which was breaking RCTFabric podspec.
This diff fixes that.
## Changelog:
[Internal] - Bring back `RCT_NEW_ARCH_ENABLED` to Fabric to make the `RCTThirdPartyFabricComponentsProvider` work again.
Reviewed By: cortinico
Differential Revision: D53048270
fbshipit-source-id: d21e833c10b332fb70147cc65b690f88016655e6
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:
Bumping the Docker image we use to build Android from Ubuntu 20.04 to 22.04
## Changelog:
[INTERNAL] - Build Android on Ubuntu 22.04
Pull Request resolved: https://github.com/facebook/react-native/pull/42618
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D53003492
Pulled By: cortinico
fbshipit-source-id: 547d19628e67aeb7a6d32e0a006673c909b55f32
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:
Those scripts are all dead, and should not be used anymore.
I'm removing them.
## Changelog:
[INTERNAL] - Remove dead android scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/42612
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D52997852
Pulled By: cortinico
fbshipit-source-id: cf57177eedb8bc0f40daf7c6c5fcd1d5ba89ba32
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
Samuel Susla
Jakub Trzebiatowski
szymonrybczak
Alex Hunt
Krzysztof Magiera
Kudo Chien
Gabriel Donadel
Riccardo Cipolleschi
Luna Wei
Ingrid Wang
Moti Zilberman
Nicola Corti
Oskar Kwaśniewski
Nick Gerleman
Phillip Pan
Joe Vilches
Xin Chen
Christoph Purrer
Luna Wei
Rubén Norte
Pieter De Baets
Saad Najmi
Himanshi Goyal
LIM Albert
Moti Zilberman
Erica Klein
David Vacca