Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42656
I'm bumping the NDK to 26.1. As we already have a bump lined up to 26.0 on main,
it makes sense to go to .1 as it's declared the LTS:
https://github.com/android/ndk/wiki
Changelog:
[Android] [Changed] - Android NDK to 26.1
Reviewed By: NickGerleman
Differential Revision: D53083606
fbshipit-source-id: 12290efcfa8a72ab88c21ffe9507d08d5512d61b
Summary:
We are making some decently large changes around here, to transition Fabric away from Yoga's private API, and add new units, and CSS properties. Even confined to Fabric, we have a large matrix of different paths for parsing.
This change consolidates layout props parsing to a single, tested path, used everywhere.
Concretely, this means removing:
1. MapBuffer for ViewProps
2. Iterator style props parsing (for layout props only)
MapBuffer for ViewProps to my understanding is not currently used at all, and has been live to edits, but untested, for quite some time. Iterator style props parsing is still enabled in some configurations, but we don't want to broadly ship its current form, and haven't been able to prioritize shipping it.
Both MapBuffer, and iterator style props parser, are performance wins. If we look at seriously shipping one of these again, we should look at swapping out the current path.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D53072714
fbshipit-source-id: 0a737c8c8f50b1f2c5c0b7ff0415e84a26a06abb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42673
Fix rendering of textInput using lineHeight in android API level <28 by removing call to ReactEditText.setLineHeight.
ReactEditText.setLineHeight was introduced in API level 28 and we actually don't need to call this method
changelog: [Internal] internal
Differential Revision: D53105649
fbshipit-source-id: f2d81cfea10de84bd47efbfeac1e21837fd49a11
Summary:
If Flow can be trusted, getConstantsForViewManager always gets called with a non-null string:
1. The only call-site to getConstantsForViewManager is getViewManagerConfig: [PaperUIManager.js](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/Libraries/ReactNative/PaperUIManager.js#L36-L80)
2. And getViewManagerConfig always passes in a non-null string.
So, let's just make the native argument type a non-nullable string.
Thoughts?
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52628937
fbshipit-source-id: 0ca68b38253cf134af29974af9e36380d66895a1
Summary:
This API was used by the old architecture to lazily register/load components:
1. Load a ViewManager's class from the disk
2. Register the ViewManager's class with React Native
See: [RCTUIManager lazilyLoadView](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/React/Modules/RCTUIManager.m#L1546-L1591)
The new architecture **does not** support lazy loading of **legacy** modules/components.
Therefore, let's leave this API unimplemented until we decide to implement lazy loading of legacy stuff in new architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52677515
fbshipit-source-id: 8d49a0b54f901a3e9b3e8a9578ebb0c81de522d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42434
Changelog: [internal]
The flags for the event loop were set up using different mechanisms due to the limitations of the previous feature flags systems. Now we can centralize on the new system and use them consistently on Android and iOS.
Reviewed By: RSNara
Differential Revision: D52819137
fbshipit-source-id: e30a6f2e12b4a027a906502b80a70dd48bb657b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42430
This PR creates a new internal feature flags system for React Native. This is only meant to be used internally within the framework, but we might expose it externally in some form in the future to allow customizing specific feature flags in frameworks and applications.
Features:
* 2 types of flags:
* Common: can be overridden from native and are accessible from all layers of the stack (Objective-C/Swift, Java/Kotlin, C++ and JavaScript).
* JS-only: flags that can only be defined and accessed from JS (to allow things like hot reloading without a native build).
* 1 source of truth for each flag.
* Feature flags are application/process scoped (using C++ singletons).
See the `README.md` file in this PR for additional information.
This also adds modifies `run-ci-javascript-tests` to run a new check to make sure that the generate files are in sync with the JSON file that contains the definitions.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52806730
fbshipit-source-id: 0ba95803f61ec2f05266ee535921321bf6d3dc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42655
This bug is caused by a caching issue: when the user enters a new character into the textInput: ReactTextInput 1) caches the Spannable entered by the user and 2) it updates internal Fabric state, which triggers the measurement of the TextInput component using the cached Spannable.
The problem is that the Spannable entered by the user has the wrong "styles" for the text input. Since measurement is using the cached Spannable, then the measurement of the TextInput ends up being is incorrect.
In this diff I'm fixing the bug by updating the styles (lineHeight) of the cached spannable that is cached when the user updates the TextInput.
The styles weren't updated correctly because mTextAttributes didn't have the proper style props set
Changelog:
[Android][Fixed] - Fix incorrect measurement of TextInput when new architecture is enabled
Reviewed By: javache, sammy-SC
Differential Revision: D52924982
fbshipit-source-id: ced9f2c348bdb9bf706028b1063858cebd5a071a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42659
Those folders for Java don't exist anymore, I'm removing this as it's unnecessary and will default to only src/main/java.
For resources instead, I'm using `setSrcDirs` as it will replace the default, while `srcDirs()` will add those folders.
We need to replace the default res folder as we need to follow the resource folder structure of BUCK
Changelog:
[Internal] [Changed] - Cleanup srcSet for java and res
Reviewed By: cipolleschi
Differential Revision: D53083677
fbshipit-source-id: 4dc42c700ea5446bbd49c63fc43b58ba316f4944
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42600
Disentangled the logic for emitting touches to JS on Android. `receiveTouches` should never be used as a public API, as TouchEvents can be dispatched just like any other event, and receiveTouches is an internal helper for `TouchEvent`.
Changelog: [Android][Removed] Updated migrated guidance for EventEmitter and reduced visibility of internal TouchesHelper methods
Reviewed By: cortinico
Differential Revision: D52907393
fbshipit-source-id: a8207039c863ab23a1d93dd2d2f28e8a274c8ecf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42660
Calling `maybeLoadSoLibrary` from init is too late, as we call `initHybrid` before `init`. Instead use a static initializer.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53048065
fbshipit-source-id: dfd2957fd9209e02c498ee08e9cbd7c7a1a83c3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42657
When the RCT_DEV flag is turned on, we force the eager initialization of the DevMenu at startup.
The initialization was happening in a method of the `CxxBridgeDelegate` protocol.
In bridgeless mode, we don't have the bridge, hence we don't call this method.
I need to put the initialization code in the `RCTIntance` because the only way I found to eagerly initialize a module was to tap into the `RCTTurboModuleManager` and, in Bridgeless mode, that's seemed to be the only way.
I'm open to move the code to a better place, anyway!
## Changelog:
[Internal] - Enable the DevMenu eagerly in Bridgeless mode
Reviewed By: sammy-SC
Differential Revision: D53083637
fbshipit-source-id: 219698eab77ed115ab0f4ea43911ae883a4c9e8a
Summary:
`RCTAttributedTextUtils.mm`: Split `NSAttributedString` creation to functions in preparation for adding new logic here.
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] - Refactor `NSAttributedString` creation in `RCTAttributedTextUtils.mm`
Pull Request resolved: https://github.com/facebook/react-native/pull/42595
Reviewed By: cipolleschi
Differential Revision: D53001495
Pulled By: sammy-SC
fbshipit-source-id: 52d28e48f0a9d88d44325a73c64737fc7ac97781
Summary:
Increase the readability of `CustomLineHeightSpan` by making the logic less stateful.
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] [CHANGED] - Increase the readability of `CustomLineHeightSpan`
Pull Request resolved: https://github.com/facebook/react-native/pull/42592
Test Plan:
- Prove the equivalence of the old and the new logic
- Test that the behavior of `lineHeight` doesn't change
Reviewed By: NickGerleman
Differential Revision: D53028467
Pulled By: mdvacca
fbshipit-source-id: d533bb77c8e10c29d8f2acc8cc39565d0013b03b
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