Summary:
This PR aims to make scripts building hermes locally more extensible for out-of-tree platforms. It will make it easier for forks like visionOS to add additional `elif` statements.
As a side benefit this PR fixes Hermes builds for MacOS 😄 (I've checked that it now builds correctly)
## Changelog:
[IOS] [ADDED] - make build-hermes-xcode.sh more extensible for out-of-tree platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/41387
Test Plan: Run the local Hermes build by running `USE_HERMES=1 bundle exec pod install` and check if it runs smoothly. Also, a CI check should be sufficient.
Reviewed By: dmytrorykun
Differential Revision: D51156307
Pulled By: cipolleschi
fbshipit-source-id: 1c65b84b16fc8bd0552037c6ef558543cbe03889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41381
Noticed that when scrolling VirtualizedList's CellRenderer was re-rendering due to `onCellFocusCapture` not having a stable identify. Change the interface to CellRenderer to pass in the `cellKey` in the callback to save on creating new callbacks.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51112928
fbshipit-source-id: 3fcb974d9b5585403895746fbc45f2cf5a9fa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41342
While rewriting `Debugger.getScriptSource` messages to fetch code and source map over HTTP, we weren't checking the status code of the fetch calls. This diff fixes that and adds corresponding tests (as well as for the filesystem error case).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D51013054
fbshipit-source-id: 58e7bb9fcd6a3cf92329b43fb8a139093c80d305
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41341
* Extends `dev-middleware`'s test utilities to enable testing against an HTTPS server with a self-signed cert.
* Runs the CDP transport integration tests (D51002261) using both HTTP and HTTPS.
* Adds a test to explicitly cover the `ws=...` / `wss=...` variation in `devtoolsFrontendUrl` first introduced in D49158227.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51006835
fbshipit-source-id: df3db8cd865898248cd0d8f307f75949a7f313fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41335
`inspector-proxy` has special behaviour to allow a debugger connection to persist across app reloads.
In the React Native runtime, a reload is modelled as the creation of an entirely new "page" with its own ID. To insulate the debugger from this detail, the proxy advertises a separate, synthetic page on each device, with ID `-1`, that always maps to the latest React Native page reported by that device.
Here we test the message forwarding part of this functionality. The proxy also injects CDP messages (in both directions) as part of simulating a reload, but that will be tested in a separate diff.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51002262
fbshipit-source-id: 296135177321a511ebbe7d9696e4e7a61275aa32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41343
Changelog: [Internal]
Adds basic tests for two-way communication between a debugger (frontend) and a target (backend) using CDP over `inspector-proxy`.
Reviewed By: blakef
Differential Revision: D51002261
fbshipit-source-id: 44e571f89437c26e76ef6e6192b2bf6244665cf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41331
`inspector-proxy`'s `Device` class currently leaks a `setInterval` handle. This is mostly harmless in current usage. In the test suite added up the stack, it shows up as a leak that prevents Jest from exiting cleanly, so let's clean it up properly.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51002263
fbshipit-source-id: ca36797ce1196aa049ceb3a8e96ee53d34893fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41314
Changelog: [Internal]
Adds the beginning of a test suite for `inspector-proxy`. For maintainability, we only test functionality exposed from the `dev-middleware` boundary rather than instantiating `InspectorProxy` directly.
In this diff, the test coverage is far from complete, but this is a first stab at covering some basics. `InspectorProxyHttpApi-test` exercises the HTTP GET endpoints (`/json/list` and `/json/version`) as well as some device registration logic through the `/inspector/device` WebSocket. Some reusable helpers for server setup and device mocking are included in separate files.
As an overall strategy, I'm planning to add multiple test files that share helpers between them, not build out one massive test file with all the helpers inline. There will likely be some verbose tests when we start covering debugger-to-device communication, and I want to keep them as readable as possible.
Reviewed By: blakef
Differential Revision: D50980467
fbshipit-source-id: 962dae5a380451d6dac57eac23c4436550a39cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41359
This change migrates the remaining podspecs to the new functions, so we do not depend on hardcoded values anymore and we can scale the solution to other platforms.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068403
fbshipit-source-id: 4c0455543363ccf4272d5e8590a7c663d9c33e8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41358
This change expose a missing function to create Header Search Paths when a podspec can't depend on another one explicitly.
This also migrate the ruby code to this new function.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068390
fbshipit-source-id: ba9e09cd2f0671a9f3f00cc72496a0d5682eeb90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41357
This change migrate React-RCTBlob to the new add_dependency to improve its compatibility with macOS and to remove some maintenance burden.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030365
fbshipit-source-id: c4b9037d6d0223052d659c04a1f494508944ed2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41356
React-Core does not depends on any bit of ReactCommon, React-RCTFabric or React-NativeModuleApple, so I'm cleaning that up.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030115
fbshipit-source-id: f87dbfe99e90d52cf8c07057be22cd024e38db42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41355
This change expose a new API to react_native_pod to add dependencies that automatically configure their search paths when using frameworksa and with multiple Apple platforms.
It also migrates React-RCTAppDelegate to this new mechanism to test that it works.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51029484
fbshipit-source-id: 77dfe85419d495f7327a2f484d33f9ed8701e00d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41354
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that automate adding a dependency to a podspec and it generates the required search paths.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51027343
fbshipit-source-id: 33ac4c07112eacb08067220397e38db0a19240fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41353
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that should factor out the platforms from the generation of header search paths.
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51026356
fbshipit-source-id: 7cf03601d94d7680f3fdfcaf52b2fd6bcd48c5b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39036
Changelog: [General][Changed] Use `hermes-parser` instead of `flow-parser` to parse Flow Codegen specs.
`hermes-parser` is a WASM build of the Hermes parser (plus supporting code), maintained by the Flow and Hermes teams. It is the recommended way of parsing Flow code in Node and its benefits (compared to `flow-parser`) include better performance and improved type safety.
Here we update `react-native/codegen` to use `hermes-parser` instead of `flow-parser`. Both parsers produce ASTs that conform to the ESTree spec so this is mostly a drop-in replacement.
In future work we should be able to use the improved AST types available in `hermes-estree` to improve type safety within `react-native/codegen` itself.
Reviewed By: huntie
Differential Revision: D48384078
fbshipit-source-id: 310ad150ec62671ba395b0e2f6415ccae97ac04d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39035
Changelog: [General][Fixed] Flow syntax errors in Codegen specs are no longer ignored.
Instead of throwing errors like most parsers, the `flow-parser` package returns errors as part of the AST (along with a best-effort parse). It turns out that `react-native/codegen` ignores such errors and only detects a subset of them after the fact. Here we change the behaviour to immediately throwing a descriptive error message (containing the file name and a code frame).
**This change is theoretically breaking** for any published packages that already contain broken Flow code (that somehow doesn't happen to affect the Codegen output today). Hopefully, anyone using Flow-flavoured RN Codegen is also typechecking with Flow and/or building with Metro (which would both flag the same errors), so the impact should be fairly contained.
Reviewed By: huntie
Differential Revision: D48385786
fbshipit-source-id: c7e1f5fb64a61fb0eb9e9f8f7501b43264c9626c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41346
X-link: https://github.com/facebook/yoga/pull/1452
This removes the last remnant from `Yoga-interna.h`, `YGNodeDellocate()`. The API is renamed to `YGNodeFinalize` to give it the explicit purpose of freeing the node from a garbage collector, and made public with that documented contract.
With that, every top-level header is now a public API, and Yoga's JNI bindings do not need to rely on private headers anymore.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51014340
fbshipit-source-id: 553f04b62c78b76f9102cd6197146650955aeec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41305
X-link: https://github.com/facebook/yoga/pull/1448
This should not be part of Yoga's API. If benchmarks want to do this, they still can (though I don't know the ones we have for it are super valuable).
Reviewed By: javache
Differential Revision: D50963933
fbshipit-source-id: 6482bd269928188b6469a358ffde5c4f9f5f9527
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41301
Adding the new API for creating UIManager(`FabricUIManager`) for Fabric initialization:
```
createUIManager(ReactApplicationContext reactApplicationContext)
```
and `FabricUIManagerProviderImpl()` and making it also implement the `UIManagerProvider` interface
NOTE:
Letting the older implementations in place and will be removed once the references have been removed from the apps and similarly for old constructor `FabricUIManagerProviderImpl()` and similarly for old implement relationship with `JSIModuleProvider`
Changelog:
[Internal] internal
Reviewed By: javache, philIip, mdvacca
Differential Revision: D50783295
fbshipit-source-id: 767f27c7f0d42840a5dad693e98cf5b6a243f933
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41296
As part of adding new implementation for `FabricUIManagerProviderImpl` APIs renaming the old class `FabricJSIModuleProvider` -> `FabricUIManagerProviderImpl` so as to add the new APIs later and preserve history.
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50949208
fbshipit-source-id: b833c4783b383c175fa682c558d31d8ecfa9f0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41364
Initializing UndefinedColor on iOS and Android is trivial because the platform color is an int32_t. On platforms where the HostPlatformColor header defines a color as a struct (e.g., Windows) it is less trivial to compose a constexpr for the undefined color representation to initialize this static const value with.
As it turns out, UndefinedColor is only used for operator bool in SharedColor, so it's reasonably safe to remove this "public" API (also good to limit the surface of SharedColor).
## Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D51073395
fbshipit-source-id: 375e43aa9a30d394d35ce2946224563738d8973c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41330
D41564032 made `console.log` (as well as `debug` and `info`) a noop in tests within the React Native repo. Here we allow them through while still throwing errors on `console.error` and `console.warn`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51002264
fbshipit-source-id: 44ca8bef38695dd76fe509341adced887bef2e6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41293
X-link: https://github.com/facebook/yoga/pull/1446
NickGerleman pointed out that my recent changes to fix the slew of row-reverse problems in Yoga actually ended up regressing some parts. Specifically, absolute children of row-reverse containers would have their insets set to the wrong side. So if you set left: 10 it would apply it to the right.
Turns out, in `layoutAbsoluteChild` there were cases where we were applying inlineStart/End values to the flexStart/End edge, which can never be right. So I changed the values to also be flexStart/End as the fix here.
Reviewed By: NickGerleman
Differential Revision: D50945475
fbshipit-source-id: 290de06dcc04e8e644a3a32c127af12fdabb2f75
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41209
X-link: https://github.com/facebook/yoga/pull/1439
There are so many instances in this code base where we use the double negative of `!yoga::isUndefined(<something>)`. This is not as easy to read since because of this double negative imo. Additionally, sometimes we have really long chains like `!longVariableName.longFunctionName(longArgumentName).isUndefined()` and it is hard to see that this undefined is inverted.
This just replaces all instances of inverted `isUndefined()` with `isDefined()` so its easier to read.
Reviewed By: NickGerleman
Differential Revision: D50705523
fbshipit-source-id: edc7d3f2cbbae38ddaeb2030a419320caf73feff
Summary:
X-link: https://github.com/facebook/yoga/pull/1437
Pull Request resolved: https://github.com/facebook/react-native/pull/41208
Reading through the sizing logic and this seemed a bit redundant/confusing. Lets use the same function we just used for the main axis for the cross axis as well so people do not think its special. Also we will need one less variable. The reason this was done it seems is because we need the leading padding + border elsewhere so this is technically a few less steps but this is cleaner
Reviewed By: NickGerleman
Differential Revision: D50704177
fbshipit-source-id: 1a091edbfee6482a2bf472aca2980702bd75ad94
Summary:
When bridgeless is enabled, RN Tester New Architecture examples crashed with a StackOverflow Exception
The root cause of this issue is that MyLegacyViewManager is sending an event to JS during the execution of MyLegacyViewManager.createViewInstance() method.
This is a problem because the delivery of events depend on the "id" of the view, but the "id" of the view is set after MyLegacyViewManager.createViewInstance() finishes executing.
The documentations "implicitly" mentions to not set props during the execution of the ViewManager.createViewInstance() method:
https://reactnative.dev/docs/native-components-android#2-implement-method-createviewinstance
To fix this issue I'm removing the execution of the method that triggers the event.
bypass-github-export-checks
changelog: [Android][Fix] Fix rendering of 'RN Tester New Architecture examples' when bridgeless is enabled
Reviewed By: fkgozali
Differential Revision: D51047007
fbshipit-source-id: 17be493f79114fa402029063e79fabc1d90efc17
Summary:
`Activity` is the current candidate name. This PR starts the rename work
by renaming the exported unstable component name.
NOTE: downstream consumers need to rename the import when updating to
this commit.
DiffTrain build for commit https://github.com/facebook/react/commit/ce2bc58a9f6f3b0bfc8c738a0d8e2a5f3a332ff5.
Reviewed By: tyao1
Differential Revision: D50945046
Pulled By: kassens
fbshipit-source-id: be9b3254c7a98840b0769135770e9bf7858cf1a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41345
## Changelog:
[Internal] -
This API was already accessible on the Android platform, now other platforms (C++) would benefit from having it available as well.
Arguably, it's perfectly fine to have it as public class members - based on empiric experience with the use case we have had.
Reviewed By: christophpurrer
Differential Revision: D51031340
fbshipit-source-id: 0426deede5d9e5c552c92f8a25d30fe2274a1941
Summary:
Though not currently in use in the RN code, when `react-native-windows` tried to integrate changes up to 7/28/23 (see PR https://github.com/microsoft/react-native-windows/pull/11970) there happened to be a `??=` operator in the `virtualized-lists` package (see [diff here](https://github.com/facebook/react-native/compare/ccc50ddd2...c168a4f88#diff-abeff2daf5909e54a23562e43569de1d5b8db1d7170119eed485b618cdf04ec7R322)). (The offending line was removed in a later commit).
The default RNW engine is still Chakra and it couldn't handle the syntax. It looks like the `babel/plugin-proposal-nullish-coalescing-operator` plugin only handles `??`, so to handle `??=` I've added `babel/plugin-proposal-logical-assignment-operators`, which also happens to handle the logical assignment operators `||=` and `&&=`.
Closes https://github.com/facebook/react-native/issues/31704
## Changelog:
[GENERAL] [FIXED] - Add detection of logical assignment operators to `react-native-babel-preset`
Pull Request resolved: https://github.com/facebook/react-native/pull/39186
Test Plan: We started using these plugins in RNW's babel config to resolve the issue in our integrate PR.
Reviewed By: motiz88
Differential Revision: D50936554
Pulled By: rozele
fbshipit-source-id: 0a924b6085524d8c9551a158b91195b1f7448c19
Summary:
This PR fixes a small typo in `build-ios-framework.sh`
## Changelog:
[INTERNAL] [FIXED] - Typo in `build-ios-framework.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/41325
Test Plan: Check if correct error message is printed out
Reviewed By: dmytrorykun
Differential Revision: D51022361
Pulled By: cipolleschi
fbshipit-source-id: 93c3e85eff8e410bcb18302dcb3ac76583d6e304
Summary:
zfrankdesign reported that in RN 0.72.6, they receive warnings that some new props listed in the documents are missing:
View tabIndex https://reactnative.dev/docs/view#tabindex-android and Text userSelect https://reactnative.dev/docs/text#userselect. It seems the components accept these props but they were not typed.
## Changelog:
[GENERAL] [FIXED] - Missing typings for the props `tabIndex` for **View** and `userSelect` in the **Text** props were added.
Pull Request resolved: https://github.com/facebook/react-native/pull/41312
Test Plan:
1. Instantiate a component of type View
1.1. Should add the property tabIndex to the View component.
1.2. Should not see a warning about the missing tabIndex property.
2. Instantiate a component of type Text
2.1. Should add the property userSelect to the Text component.
2.2. Should not see a warning about the missing userSelect property.
Reviewed By: NickGerleman
Differential Revision: D50982156
Pulled By: lunaleaps
fbshipit-source-id: 75b55cfb897738be0cf426912a7c10c7412d5032
Summary:
Closes https://github.com/facebook/react-native/issues/41236
`setState` is not working properly for text inline image
## Fixed demo (please see the animation as in rendering pass rather than re-mounting pass)
https://github.com/facebook/react-native/assets/149237137/d4b894bf-2283-4963-8dc7-b8f5a9f81315
## How it works
**Background**
Inline views are not included in the Yoga node tree, rather, they are retained as attachments of `NSAttributedString` and are managed by the respective text fragment (`RCTTextShadowView`) that includes them (Code snippet 1).
```
<div layout="width: 393; height: 852; top: 0; left: 0;" style="" >
<div layout="width: 393; height: 852; top: 0; left: 0;" style="flex: 1; " >
<div layout="width: 393; height: 852; top: 0; left: 0;" style="flex: 1; " >
<div layout="width: 393; height: 241; top: 0; left: 0;" style="padding-top: 59px; " >
<div layout="width: 393; height: 50; top: 59; left: 0;" style="width: 100%; height: 50px; " >
<div layout="width: 393; height: 17.3333; top: 0; left: 0;" style="" has-custom-measure="true"></div>
</div>
<div layout="width: 393; height: 50; top: 109; left: 0;" style="width: 100%; height: 50px; " >
<div layout="width: 393; height: 17.3333; top: 0; left: 0;" style="" has-custom-measure="true"></div>
</div>
/* Text node that does not contain inline view that is supposed to be there */
<div layout="width: 393; height: 74.3333; top: 167; left: 0;" style="margin-top: 8px; " has-custom-measure="true"></div>
</div>
</div>
</div>
</div>
```
**Code snippet 1, output of YGNodePrint() in _normal layout_ flow**
The layout of such node is handled ad-hoc (_inline layout_) inside `RCTTextShadowView` (Code snippet 2)
```
/* Inline node is calculated on its own */
<div layout="width: 48; height: 48; top: 0; left: 0;" style="overflow: hidden; width: 48px; height: 48px; min-width: 0px; min-height: 0px; " ></div>
```
**Code snippet 2, output of YGNodePrint() in _inline layout_ flow**
**Problem description**
The issue happens when the sizes given by `setState()` are smaller than those in the last round `setState()`. Since the `min-width` and `min-height` are already populated (Code snippet 3) with greater values, the new layout pass gives rather a `noop`.
```
/* min sizes are greater than them in the new style */
<div layout="width: 48; height: 48; top: 0; left: 0;" style="overflow: hidden; width: 32px; height: 32px; min-width: 48px; min-height: 48px; " ></div>
```
**Code snippet 3, output of YGNodePrint() in _inline layout (issue)_ flow**
**Fix description**
This biased `min-width` and `min-height` are given using the **current frame size** (i.e., sizes set in the last round `setState()`) in the _inline layout_ (in `RCTTextShadowView` § Background), whilst the same parameters are given as ~~CGSizeZero~~ `_minimumSize` in _normal layout_ (§ Background).
The change of this PR is to unify this behavior of _normal layout_ by using ~~CGSizeZero~~ `_minimumSize` as the input also for _inline layout_.
## Changelog:
[IOS] [FIXED] - `setState` is not working properly for text inline image
Pull Request resolved: https://github.com/facebook/react-native/pull/41287
Test Plan:
- Using **rn-tester** for basic verification
- Complete plan: https://docs.google.com/spreadsheets/d/1QLuqNvqX0dM4K68ygRoHDR3S0wcK5umptmjoR7KtkaY/edit?usp=sharing
Reviewed By: cipolleschi
Differential Revision: D50967547
Pulled By: NickGerleman
fbshipit-source-id: b3b6d6919fd9d3302977dc771a41c22f7b796ba5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41309
Changelog: [Internal][Removed] CxxModuleWrapper.makeDSO is not actively used and has been replaced by TurboModule infra.
Reviewed By: NickGerleman
Differential Revision: D50878589
fbshipit-source-id: 9fd11c1ee860ea65f1e985a132de3216ed042752
Summary:
We're logging a systrace section that for some reason is breaking the data in application traces. That section isn't especially relevant so we can just remove it.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50939346
fbshipit-source-id: 350a528d83c6fe6e7100275644d3d02a96700e59
Oskar Kwaśniewski
Pieter De Baets
Intl Scheduler
hieu9102002
Moti Zilberman
Riccardo Cipolleschi
Nick Gerleman
Arushi Kesarwani
Eric Rozell
Joe Vilches
David Vacca
kassens (Meta Employee)
Alex Zelensky
Ruslan Shestopalyuk
George Zahariev
Jon Thysell (JAUNTY)
szymonrybczak
Jorge Luis Calleja Alvarado
ehsemloh
Samuel Susla
Rubén Norte