Summary: I've noticed that Bridge and Bridgeless initialize the list of ReactPackages using a different order, we are fixing it in this diff
Reviewed By: philIip
Differential Revision: D52145148
fbshipit-source-id: 6ad85bd0903f9beab455783e8deaf5c529b87a2e
Summary:
Since yesterday evening (why it is always friday evening???) CircleCI or Gem decided to update the default bundler version that is installed with `gem bundle install`.
Therefore, CI for iOS stopped working.
This change installs bundler's versions so that they are compatible with the Ruby version.
## Changelog:
[Internal] - Fix CI for iOS installing versions of bundler that are compatible with Ruby
Pull Request resolved: https://github.com/facebook/react-native/pull/41962
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D52230544
Pulled By: cipolleschi
fbshipit-source-id: 2f96e16ecb94159953056e8de757ea4d249f80f0
Summary:
X-link: https://github.com/facebook/yoga/pull/1513
Pull Request resolved: https://github.com/facebook/react-native/pull/41916
Fixes https://github.com/facebook/yoga/issues/1300
Fixes https://github.com/facebook/yoga/issues/1008
This fixes a smattering of issues related to both sizing and aligment of multi-line-containers:
1. We were previously incorrectly bounding the size of each flex line to the min/max of the entire container.
2. Per-line leads were sometimes incorrectly contributing to alignment within the line
3. The cross dim size used for multi-line alignment is not correct, or correctly clamped. If the available size comes from a max constraint, that was incorrectly used instead of a definite size, or size of content. Leads were entirely skipped for min constraint.
Need to test how breaking this is, to see if it might need to go behind an errata.
See related PRs:
1. https://github.com/facebook/yoga/pull/1491
2. https://github.com/facebook/yoga/pull/1493
3. https://github.com/facebook/yoga/pull/1013
Changelog:
[General][Fixed] - Fix Yoga sizing and alignment issues with multi-line containers
Reviewed By: joevilches
Differential Revision: D52087013
fbshipit-source-id: 8d95ad17e58c1fec1cceab9756413d0b3bd4cd8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41931
`GenericStyleProp` is defined as
```
type GenericStyleProp<+T> =
| null
| void
| T
| false
| ''
| $ReadOnlyArray<GenericStyleProp<T>>;
```
and `____FlattenStyleProp_Internal` is designed to reverse it. We can use conditional type to achieve it instead of $Call:
`null | void | false | ''` doesn't contribute to anything doing reversal, so they are mapped to empty. When we encounter $ReadOnlyArray, we recursively apply `____FlattenStyleProp_Internal`. Otherwise, we return the input type.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D52142082
fbshipit-source-id: 590c71c6400498730675e20c67b173c3bc285d00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41782
This diff adds `outputDir` property to `codegenConfig`.
Now codegen output dir is resolved like this:
1. It is set to `outputDir` argument of `generate-codegen-artifacts.js` if it is present.
2. *[New]* It is set to `outputDir` property of `codegenConfig` if it is present.
3. It is set to the project root.
Changelog: [General][Added] - Introduce "outputDir" property of "codegenConfig"
Reviewed By: cipolleschi
Differential Revision: D51494009
fbshipit-source-id: 0f6e3607b29a3c6d228a88a9460d55bb65c7e55a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41944
Changelog: [iOS][Deprecated]
i think we can now communicate the deprecation of this selector.
after removing all of the synthesize methodQueue callsites in our codebase, our native modules are still stable, save for one native module, RCTNetworking. so i feel comfortable recommending users to create their own queues.
and after removing `methodQueue` overrides to support synchronous void methods, those modules are also still stable, so i'm also comfortable we can recommend handling the dispatch_async in the product layer.
Reviewed By: arushikesarwani94, cipolleschi
Differential Revision: D52150696
fbshipit-source-id: ff6b90fc685796e5560167f1377a76526ee07744
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41942
Previously, every time a component was updated, we were passing all the props to the interoperated component.
With this change, we are going to only pass the props that are changed.
As a safety feature, if the new codepath is not able to detect the type of the prop properly, it will fall back to the previous behavior.
## Changelog:
[Internal] - Only pass props to the interoperated component when they changes
Reviewed By: sammy-SC
Differential Revision: D51755764
fbshipit-source-id: 0185d2cceeab2a1e45b87d5a1e82ab06e00aa82d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41941
While working on the interop layer, I realized that htis code is duplicated.
## Changelog
[Internal] - Use the same method for View And ShadowView in the Interop layer
Reviewed By: sammy-SC
Differential Revision: D51752171
fbshipit-source-id: 579652de262fea7edb13a1329cb07683eab78124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41923
Changelog: [Internal][BREAKING] Use C++ enum classes in C++ Turbo Modules
Problem:
Using **C styles** `enums` can easily cause compiliation errors if symbol names collide. This code does not compile:
```
enum CustomEnumInt { A = 23, B = 42 };
static int A = 22;
```
This **C++ code**, using `enum classes` compiles:
```
enum class CustomEnumInt : int32_t { A = 23, B = 42 };
static int A = 22;
```
Reviewed By: rshest
Differential Revision: D52098598
fbshipit-source-id: c919bd2e41970c83a032fec91b0537cd6fae8397
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41903
These offset methods are supposed to be in reference to the node's nearest positioned (non-static) ancestor: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetParent. Right now, because static did not exist, they return the offset from the parent. This changes it so that the API is spec compliant and will look at the position of its ancestors before settling on the right offset. I added a helper `getNewestPositionedAncestorOfShadowNode` to get the correct node. Then I use that to calculate the proper offset
Changelog: [Internal]
Reviewed By: rubennorte, NickGerleman
Differential Revision: D51414950
fbshipit-source-id: ebc8de1d3a0f3e9485f63e792b5bef5b9151460d
Summary:
When using `RCT_EXTERN_REMAP_MODULE` a warning is produced with the following message: "A function declaration without a prototype is deprecated in all versions of C". This warning can be silenced by setting the `CLANG_WARN_STRICT_PROTOTYPES ` build setting. However this PR addresses the underlying problem resulting in no warning messages.
## Changelog:
[IOS] [FIXED] - Fixed strict prototype warning when using the RCT_EXTERN_REMAP_MODULE macro.
Pull Request resolved: https://github.com/facebook/react-native/pull/41805
Reviewed By: NickGerleman
Differential Revision: D51891880
Pulled By: dmytrorykun
fbshipit-source-id: 7804d624b248b568643956a8a7b7e0f8540b5ae2
Summary:
When publishing my RN fork I hit this issue where a RCTThirdPartyFabricComponentsProvider module would end up in the npm tarball which causes build issues. This file is generated by codegen and should never be included.
## Changelog:
[INTERNAL] [FIXED] - Ignore RCTThirdPartyFabricComponentsProvider for npm publish
Pull Request resolved: https://github.com/facebook/react-native/pull/41868
Test Plan: Tested that the file is no longer included when publishing my RN fork
Reviewed By: christophpurrer
Differential Revision: D52032223
Pulled By: dmytrorykun
fbshipit-source-id: a846813176d60119d97261131fd9d9a6aa919e62
Summary:
The height returned by TextInput's 'onContentSizeChange' callback method is incorrect
Because, the borderwidth and horizontal padding are not subtracted from the content width used to calculate the height of the text.
I have seen many people in the same situation in many issues. When I solved, some people suggested I submit a PR.
More information can be found here [https://github.com/facebook/react-native/issues/35234](https://github.com/facebook/react-native/issues/35234#issuecomment-1831141903)
## Changelog:
[IOS] [FIXED] - the wrong height result of onContentSizeChange callback
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/41803
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D51891909
Pulled By: dmytrorykun
fbshipit-source-id: fa297155ebdfc933cf0ea6bcdab37d7410809e8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41914
If the user does not specify which engine they're using, we still default to loading JSC first and then attempting to load Hermes.
This has a small performance hit (as we attempt to load an existing library) + it prints an inactionable log for the user every time.
Changelog:
[Android] [Fixed] - Update getDefaultJSExecutorFactory to load Hermes first and fallback to JSC
Reviewed By: luluwu2032
Differential Revision: D52080545
fbshipit-source-id: 95f37304d713da7d7079eabbd2dfdf230d29a1b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41912
Progress towards an opt-in setup for our new CDP backend.
- For `DevSupportManagerBase` on Android: Conditionally omit sending `Debugger.disable` CDP message when new CDP backend is enabled.
Reviewed By: motiz88
Differential Revision: D52040149
fbshipit-source-id: 452f46395261d2d9670bd38192d06e6fa8e1f93f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41913
Progress towards an opt-in setup for our new CDP backend.
- Adds and configures an [fbjni](https://github.com/facebookincubator/fbjni) interface for reading `jsinspector_modern::InspectorFlags`, allowing access in Java contexts.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D52040150
fbshipit-source-id: 5459eda2747279633a8312a3979ba29a1e0d1bde
Summary:
There is currently an error when building in release on iOS when using asset catalogs (experimental feature that is partially merged https://github.com/facebook/react-native/pull/30129)
This was probably incorrectly migrated from the community cli repo. `.imageset` is actually folders so it needs to be removed with `{recursive: true, force: true}`. I also renamed the variable `files` which is confusing since its folders.
## Changelog:
[IOS] [FIXED] - Fix cleanAssetCatalog error
Pull Request resolved: https://github.com/facebook/react-native/pull/41865
Test Plan: Tested in an app that uses asset catalogs
Reviewed By: NickGerleman
Differential Revision: D52032258
Pulled By: huntie
fbshipit-source-id: 1dc0ca09e0da0d514b03d7d72707bdcaef03301d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41831
The build is currently firing several build warnings due to the Groovy -> Kotlin migration.
I've fixed them all over here.
Changelog:
[Internal] [Changed] - Resolve several Gradle build warning
Reviewed By: mdvacca
Differential Revision: D51890225
fbshipit-source-id: 4a2ff9dc168fca62893db704e282793e0bf03653
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41832
I'm removing the `installArchives` task and all the setup to publish
the Maven Local inside the NPM package as we're not using this entirely
and we won't be able to use it anyway (as the Maven Local is too big to fit an NPM package).
Changelog:
[Internal] [Changed] - Remove the installArchives task
Reviewed By: GijsWeterings
Differential Revision: D51890224
fbshipit-source-id: 3ffdc67a9fe931118596f6f74a5a2df0313ca3f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41834
I'm updating other two `build.gradle` to `build.gradle.kts` files.
The only functional change I made was to remove the function to check if major >= 1 and turn on New Architecture. This needs to be moved to RNGP as Kotlin doesn't have dynamic accessors to Object so we can't convert that function.
Changelog:
[Internal] [Changed] - Convert ReactAndroid and RN-Tester to Kotlin DSL
Reviewed By: mdvacca
Differential Revision: D51856356
fbshipit-source-id: ef75579cd3ec121ef6ac9a357c1e10bcf9995432
Summary:
The logic to constrain the last spacer size is incorrect in some cases where the spacer is the last spacer, but not the last section in the list.
For more context, the role of spacer constraining is explained in this comment:
```
// Without getItemLayout, we limit our tail spacer to the _highestMeasuredFrameIndex to
// prevent the user for hyperscrolling into un-measured area because otherwise content will
// likely jump around as it renders in above the viewport.
```
For example it is incorrect in the case where we have:
ITEMS
SPACER
ITEMS
In this case the spacer is not actually the tail spacer so the constraining is incorrectly appied.
This causes issues mainly when using `maintainVisibleContentPosition` since it will cause it to scroll to an incorrect position and then cause the view that was supposed to stay visible to be virtualized away.
## Changelog:
[GENERAL] [FIXED] - Fix last spacer constrain logic in VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/41846
Test Plan:
Tested using https://gist.github.com/janicduplessis/b67d1fafc08ef848378263208ab93d4c in RN tester, before the change content will jump on first click on add items.
Tested using the same example and setting initial posts to 1000, then we can see our content view size is still constrained properly (see scrolling indicator as reference).
Reviewed By: yungsters
Differential Revision: D51964500
Pulled By: NickGerleman
fbshipit-source-id: 4465aa5a36c95466aef6571314973c1e2c9a0f2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41672
Progress towards an opt-in setup for our new CDP backend.
- Adds `InspectorFlags.h`, a singleton intended to allow convienient access to static boolean feature flags for the new CDP backend/inspector features across platforms. This will be written to in upcoming diffs, with the accessor for `enable_modern_cdp_registry` soft-defaulting to `false` here.
- References this to conditionally disable legacy ~CDP registration in `HermesExecutorFactory` (Bridge) and `HermesInstance` (Bridgeless) code paths.
- Stubs a `false` value for `react_native_devx:enable_modern_cdp_registry` in `EmptyReactNativeConfig` (documentation/convenience point for open source partners and integrators).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51563107
fbshipit-source-id: 446f319228ec627fdc0ecba9517a1a3faad9d262
Summary:
X-link: https://github.com/facebook/yoga/pull/1497
The lowest common denominator we have had for Yoga has been Clang 12 + MSVC 2017 stdlib. This has allowed Yoga to use C++ 20 language features, but not library features. React Native for mobile has not been bound to this restriction.
Builds using that toolchain are being updated to latest MSVC 2019 stdlib (which has good C++ 20 library support), along with Clang 17 (or maybe a stop at 15) pending projects using `-fcoroutines-ts` being migrated to C++ 20.
This tests out some C++ 20 standard library usages against the current Clang 12 + MSVC 2019 stdlib toolchain that didn't work before, and adds a couple concepts for better constraints/compiler error messages if misused.
This bumps min-tested XCode (and minimum required) version to 14.3, matching a similar change for React Native. This should probably be bumped to 15 sometime before Apple starts requiring 15+ to go out to the iOS app store.
We are approaching a practical support range of:
1. XCode >= 14.3
2. NDK >= 26
3. Clang/libc++ >= 14
4. GCC/libstdc++ >= 11
5. MSVC >= 16.11 (VS 2019)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51604487
fbshipit-source-id: d394d0d86672b69781b8ae071d87adcf944ddc72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41866
Direct recursive member types require infinite memory and aren't possible with current hardware.
Throw parser error to make this visible.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51999832
fbshipit-source-id: 671f87325f33dd24f70ff3e2229c9d0b888d7445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41471
Changelog: [Internal] - Clean up eventTarget retaining logic in the pointer event processor
This refactors calls to EventTarget::retain/release to occur in the actual methods that require the event target to be retained instead of expecting the caller to manage that which should be more maintainable.
Reviewed By: sammy-SC
Differential Revision: D51279974
fbshipit-source-id: db7251504a44ca59e4475928af7e6cf993cfa6e3
Summary:
Why ignore for now?
- It only happen once during initialization and doesn't cause any breakages for RNTester
- The race condition happens in Android System code which is hard to tackle:
```Exception in native call
java.lang.NullPointerException: java.lang.NullPointerException
at com.facebook.jni.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:30)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:235)
at java.lang.Thread.run(Thread.java:1012)
```
From stack trace message.callback is checked in
```at android.os.Handler.dispatchMessage(Handler.java:99)```
but becomes null in
```at android.os.Handler.handleCallback(Handler.java:958)```
[Android source code](https://l.facebook.com/l.php?u=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Fcore%2Fjava%2Fandroid%2Fos%2FHandler.java&h=AT1aQS0Vmknao8kLbYE_hhLj1G3idUf69jFQE3ZLAqjrbcMX4OdQUV1dzZpAkAvLaZ9HAOanpsKCC8z59Ce9XJa6cOhQL2L95gM9iMrSr7FbrpTKPLKbWjDmTz89WUL2pQprnBVKyA8) of Handler.
Reviewed By: cortinico
Differential Revision: D51550240
fbshipit-source-id: 6288e196da1da88a37f5c69bfce82e3e09c6f106
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41819
This will be needed in order to access the position type while implementing offsetLeft/Top, which needs to know if a node is static or not to get the proper offset. This is simply making the position type available to be read from LayoutMetrics.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51412428
fbshipit-source-id: b101d8065ddfe0322f77f64d1de0f9ead3975c60
Cheng Zhao
David Vacca
Riccardo Cipolleschi
Nick Gerleman
Sam Zhou
Dmitry Rykun
Zeya Peng
Alex Taylor (alta)
Phillip Pan
Riccardo Cipolleschi
Christoph Purrer
Joe Vilches
David v.Knobelsdorff
zhongwuzw
Oskar Kwaśniewski
Janic Duplessis
Lulu Wu
zyestin
Nicola Corti
Ian Park
Alex Hunt
Intl Scheduler
szymonrybczak
Yugo Ogura
Vincent Riemer
Arushi Kesarwani
Qian Wu