Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42037
Creates an Objective-C wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native iOS apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `RCTInspectorPackagerConnection` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52225495
fbshipit-source-id: f1b9657ef0d665cf7892c15c34c5104e2777ec43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42018
Creates an JNI wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native Android apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `InspectorPackagerConnection.java` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52231237
fbshipit-source-id: 5a0e3bd8b2b711c1c592db15c51df4c3cc89aaad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42197
Some std::ranges functions don't work well (or at all) when using
clang, eg see
https://fb.workplace.com/groups/474291069286180/posts/9724112847637243
This works in clang 16, but not clang 15 which fbcode is on. Note that more complicated parts of ranges work, but not these simpler helpers, funnily enough :).
As I'm trying to make RN compile in fbcode, I need clang to work.
Moving them back to iterators, but using rbegin/rend making it fairly readable still.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52481786
fbshipit-source-id: f37d4e1912b33eee392061dc787afaacd9554409
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
This PR tries to fix a build error when `import <React/RCTAppSetupUtils.h>` from *.m files. Since the `[[deprecated("")]]` syntax is a C++14 feature and it was placed inside the `RCT_EXTERN_C_BEGIN` block. If the file in imported from Objective-C *.m files or Swift files, it will have a syntax error. Instead of using the C++ syntax, this PR uses the `__deprecated_msg()` statement that is also used in other code in react-native and that is C supported syntax.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fix RCTAppSetupPrepareApp.h import error from Objective-C *.m files
Pull Request resolved: https://github.com/facebook/react-native/pull/42172
Test Plan:
- test building and importing **RCTAppSetupPrepareApp.h** from a *.m file
- test `RCTAppSetupPrepareApp(application, turboModuleEnabled)` will show a compile warning
Reviewed By: arushikesarwani94
Differential Revision: D52603421
Pulled By: cipolleschi
fbshipit-source-id: bfec8d0ba6378a265ad30dd8ca1d3ab15cff96ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42191
X-link: https://github.com/facebook/yoga/pull/1539
React native supports transforms and if a node has a transform it will [form a containing block for absolute descendants regardless of position type](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block). So we need to pass that information into Yoga to ensure this happens.
The verbiage for the field "alwaysFormsContainingBlock" is very specific. In a vacuum a node cannot simply "form a containing block". It only forms a containing block in reference to a different node. This can be illustrated in a scenario where we have a static node that is a flex container which has 1 absolute child and 1 relative child. This static node will form a containing block for the relative child but not the absolute one. We could just pass the information on rather something has a transform or not but Yoga is not supposed to know about transforms in general. As a result we have a notion of "always" forming a containing block. Since Yoga is a flexbox spec, non-absolute nodes' containing blocks will ways be their parent. If we add something like a transform to a node then that will also apply to absolute nodes - hence we can say the node will **always** form a CB, no matter who is the descendant.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52521160
fbshipit-source-id: bab9319ffddec617f5281823930f2a00cc2967f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42190
Essentially undoing D51182861 that was put in place to support adding a default position type to Fabric. Previously I had already removed the code that set the default to something other than Yoga default, but I did not remove all this extra code that allows you to do that. Since we no longer need this we should remove it so as not to encourage messing with the defaults in such a way that they differ from Yoga defaults.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52515993
fbshipit-source-id: fb4ab726cf73bf08fd6aa44b99196962a9839694
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42189
tsia, we had the equality op defaulted so might as well do this for inequality
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52515802
fbshipit-source-id: ce31a00eddda991221c91364508fed6df78fd5b4
Summary:
Adds changelog for the 0.73.2 release.
## 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] - Add changelog for the 0.73.2 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/42186
Test Plan: Read the changelog 🤞
Reviewed By: huntie
Differential Revision: D52604441
Pulled By: lunaleaps
fbshipit-source-id: 3d67da6d8ff1e3afe9a875bd38eb851fc28cd7ac
Summary:
In my mac, I use a case-sensitive volume and when I build a react-native 0.73 project it failed with an error that can't find the hermes release tarball to extract:
```
Node found at: /usr/local/bin/node
Preparing the final location
Extracting the tarball
tar: Error opening archive: Failed to open '/Volumes/Workspace/meet-art-link/ios/Pods/hermes-engine-artifacts/hermes-ios-0.73.1-Release.tar.gz'
```
Note the `...-Release.tar.gz` in the error. In the disk it's `...-release.tar.gz`.
The build fails in after download the release tarball in release mode because the hermes tarball name in the `replace_hermes_version.js` build script is capitalized, while the file is lowercase on disk.
The fix is to ensure the hermes tarball name's "build type" is lowercase just like the function that creates the tarballs in react-native release located in `hermes_utils.js` in `getHermesPrebuiltArtifactsTarballName()`.
Perhaps it's better to retrieve the tarball name from the same method it's generated? E.g.:
```js
const { getHermesPrebuiltArtifactsTarballName } = require('react-native/scripts/hermes/hermes-utils');
const tarballName = getHermesPrebuiltArtifactsTarballName(`${version}-${configuration}`);
const tarballURLPath = `${podsRoot}/hermes-engine-artifacts/${tarballName}`;
```
If yes, let me know to update the PR.
## 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
-->
[iOS][Fixed] - Fix release build error due to a casing issue in hermes tarball path after download prebuilt tarball
Pull Request resolved: https://github.com/facebook/react-native/pull/42160
Test Plan: Use a case sensitive volume or system and build react-native 0.73 in release mode, it will fail. Apply the patch in this PR and it will work fine.
Reviewed By: cortinico
Differential Revision: D52603439
Pulled By: cipolleschi
fbshipit-source-id: 41ed8d8202874f338e4aa3af88d9d28ec1b8b3d5
Summary:
Closes https://github.com/facebook/react-native/issues/42164
## Changelog:
[IOS] [FIXED] - Fixes `with-environment.sh` script for the case when Node can't be found prior to loading `.xcode.env`
Pull Request resolved: https://github.com/facebook/react-native/pull/42184
Test Plan: This is a trivial update, no need for much testing.
Reviewed By: cortinico
Differential Revision: D52602653
Pulled By: cipolleschi
fbshipit-source-id: 0881456bf165d895252ae38cb7c7aee945cfaf52
Summary:
Currently our CI will auto-tag any `npm publish` as `latest` for the monorepo packages. This is because [we do not specify a tag](https://github.com/facebook/react-native/blob/main/scripts/monorepo/find-and-publish-all-bumped-packages.js#L104), so npm will [default to `latest`](https://docs.npmjs.com/cli/v10/commands/npm-dist-tag#description). We encountered a similar issue for `react-native` awhile ago and fixed that with [always specifying a tag](https://github.com/facebook/react-native/blob/main/scripts/npm-utils.js#L84), with the explicit opt-in for `latest`.
yarn and npm will resolve `*` dependencies using `latest`. This will be a problem for any React Native version that uses `*` deps. We have actively tried to remove these `*` versions but older patches may still contain them.
When we do a monorepo package bump, it may be for 0.71 and for a user who is initializing a 0.72 version project (that still has * deps), they will receive monorepo packages of version `0.71.x`, which is not compatible. (React Native monorepo packages do not faithfully follow semver)
This change allows us to specify what tags to use and suggest tags based on what branch you are on and asks for confirmation
```
> branch 0.73-stable
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "0.73-stable"
◉ "latest"
? Confirm these tags for *ALL* packages being bumped: "0.73-stable","latest" (Y/n)
> branch 0.72-stable
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "0.72-stable"
◯ "latest"
? Confirm these tags for *ALL* packages being bumped: "0.72-stable" (Y/n)
> branch main
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "nightly"
? Confirm these tags for *ALL* packages being bumped: "nightly" (Y/n)
```
## Changelog:
[INTERNAL] [CHANGED] - Support dist-tags in publishing monorepo packages to avoid default "latest" tag.
Pull Request resolved: https://github.com/facebook/react-native/pull/42146
Test Plan: `yarn test scripts/`
Reviewed By: NickGerleman
Differential Revision: D52551769
Pulled By: lunaleaps
fbshipit-source-id: 52f923464387cffdc6ca22c6f0a45425965a3680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42158
Changelog: [Internal]
* Ports an existing Java/ObjC InspectorPackagerConnection behaviour to the C++ implementation: socket errors should trigger a reconnection. This was a simple omission in D52134592.
* Clarifies the relationship between the `didFailWithError` and `didClose` methods on `IWebSocketDelegate`: calling either one will terminate the connection (and trigger a reconnection), and it's legal to call `didClose` after `didFailWithError`.
* I'm also adding logic to ensure we don't double-schedule reconnections if both methods are called.
* Cleans up the scaffolding comments from D52134592
Reviewed By: huntie
Differential Revision: D52576727
fbshipit-source-id: 07e5a5c36222dc7bede8bcb17a1f3ced2788736b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42118
JFrog CDN periodically gives us headaches when downloading boost.
this change moves from JFrog to the official CDN by boost.
## Changelog
[Internal] - Download boost directly from boost archives
Reviewed By: cortinico
Differential Revision: D52479171
fbshipit-source-id: a53a9cb2ea6dfdf2b82b3c8e69c697b24cc40cf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42156
changelog: [internal]
Add a missing nullptr check to prevent crash if called after component was reused
Reviewed By: fkgozali
Differential Revision: D52572807
fbshipit-source-id: 1b5b26996e562abbcb986865299e02df20b58043
Summary:
https://github.com/facebook/react-native/commit/f7219ec02d71d2f0f6c71af4d5c3d4850a898fd8 deprecated some of the methods in `RCTBundleURLProvider, and is part of React Native version 0.73. Let's remove the deprecated options for React Native 0.74+
bypass-github-export-checks
## Changelog:
[IOS] [REMOVED] - Remove deprecated RCTBundleURLProvider options
Pull Request resolved: https://github.com/facebook/react-native/pull/42114
Test Plan: CI should pass.
Reviewed By: huntie
Differential Revision: D52537732
Pulled By: cipolleschi
fbshipit-source-id: ea5d17c7c66a60bceb2a12f2e17e39be4c56d422
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42022
Some tests to ensure that the order of nodes is correct as defiend by order index that is derived from zIndex + positioning. These tests do not ensure that the native platform then goes and lays them out correctly. That will be done later with e2e tests on catalyst
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52295063
fbshipit-source-id: 8ae29fc50ad65db8e5c0ab28a132546d8489dffe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42021
# Context
A while ago D48905010 was committed that set the CALayer's zPosition equal to the zIndex passed in via props. This was to avoid an issue like: https://pxl.cl/40F72
where the rotating view would clip into the background.
There are a few issues here.
* The current zIndex code is designed to be cross platform on the C++ layer and not the native layer. This diverges from the Android behavior and adds a special case for this platform when we have the ability to share all of this logic
* Static nodes will apply a zIndex when they shouldn't. This code pre-empts the static check [here](https://www.internalfb.com/code/fbsource/[cf8ad268b4cf]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/renderer/components/view/ConcreteViewShadowNode.h?lines=98) that zeroes out the "order index" for static nodes
* As a result of the above, static nodes can eclipse their children which should never happen because static nodes ignore zIndex values
# Reason for the clipping
The reason this clipping is happening is because the red/blue views share the same stacking context as the white background (as indicated by the vertical black line). {F1175070418}
This in combination with the fact that our zIndex implementation will NOT set iOS's zPosition means that these three views (red view, blue view, white background view) all have the same zPosition (0) and will be laid out in the order described by the orderIndex mentioned earlier. This index essentially just changes the document order that is used for tiebreakers when zPosition is tied.
So, all the views are on the same stacking context and they all have no zPosition set. Add the rotation that the colored views are doing and you get this clipping. Apple will change the "zPosition" in a sense for the parts of the view that should be perceived as "further away" due to the rotation. So, we clip into our background which has a lower order index but the same zPosition.
# This change
The fix here just makes it so that the rotating views are not on the same stacking context as the background so the changing zPosition from the rotation does not matter. This can be achieved by setting the zIndex of the container to any number (among other things). Note that this is only the case because the default position type is relative in this stack. Otherwise you would also need to set the position type as well. Now the stacking context looks like: {F1175083828} and the problem is solved!
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52181701
fbshipit-source-id: 580f860273b9c8470181d92d7ad542546664ed77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42064
# Context
Dealing with how we should stack Views in a world with static is actually a bit complicated, despite the fact that static cannot get zIndex. The outline of everything can be found in this spec: https://www.w3.org/TR/CSS21/zindex.html. That is a bit dense, but mainly because there is much more functionality to consider in the browser than we need to in RN (like block layout, inline, floats, etc). Basically it comes down to this order, with larger numbers stacked on top of smaller ones:
1) Root
2) Negative zIndex positioned nodes (ties in document order)
3) Non positioned nodes in document order
4) Positioned nodes with no zIndex (or 0) in document order*
5) Positioned nodes with positive zIndex (ties in document order)
Document order is a pre-order traversal of the tree. The asterisk on 4 is where it gets a bit complicated. Even though there is no zIndex set, you should still treat these nodes as if they form a stacking context - with their descendants stacked relative to the parent stacking context like normal if they have zIndex set. Essentially what this means in our world is that a static child will not come before (under) a positioned parent if they share the same stacking context. Without this, you would need to form a stacking context on all positioned nodes with static children if you wanted them to appear at all since static comes before (under) positioned nodes.
# Implementation
Implementing this was a bit tricky. We had to go in pre-order traversal of the tree, but if we see a relative node it needs to form a "pseudo-stacking-context" to allow static to show over it, but if any of those descendants have a zIndex set, that should be relative to the parent stacking context like normal, not this "pseudo-stacking-context". Without static we take care of this just fine because it just ends up being a pre-order traversal of the tree, then sort by zIndex.
My approach was to ignore zIndex's at first and gather all nodes that share the same stacking context in an array as if none of them had any zIndex set. After that was gathered, then sort by zIndex to get the final order for said stacking context. The second part was already implemented. For the first part I just did a pre-order traversal of the tree (stopping at nodes that form stacking contexts) and:
* If a node was non static, add to the end of the list
* If a node was static, insert into the list right after the previously inserted static node that shares the same "psuedo-stacking-context", or the parent if there were none.
* Since inserting into arrays is slow, I opted to use `std::list`
In effect this was a pre-order traversal where static nodes are "sorted" to come first in the list of children, which is what we want since these nodes should come under non-positioned nodes that have the same "pseudo-stacking-context".
My implementation is a bit slower. The previous one just visits all nodes once with a pre-order traversal. This will also do that and thanks to `std::list`, we have no non-constant time operations while coming in that order. After the fact, however, we need to convert back to `std::vector` which is the type used across the mounting layer, so we have to iterate over this list again. I think this is the fastest we can do this and it is optimized for a world where most nodes are relative (since it will be the new default).
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52103057
fbshipit-source-id: 0b3fb28530cfc8ef248dbdc564b5c4b4a82045a4
Summary:
This PRs refactors `RCTKeyWindow()` to be more resilient and work in multi-window apps. After my recent PR got merged (https://github.com/facebook/react-native/issues/41935) it significantly reduced the number of calls to `RCTKeyWindow()` and now it's called only when necessary. So this PR makes this function a bit more resource intensive but it guarantees that we will find current scene's key window.
This would also fix some brownfield scenarios where React Native is working in multi-window mode and in the future allow us to more easily adopt `UIWindowSceneDelegate`
bypass-github-export-checks
## Changelog:
[IOS] [CHANGED] - refactor `RCTKeyWindow` to be more resilient and work in multi-window apps
Pull Request resolved: https://github.com/facebook/react-native/pull/42036
Test Plan:
Checkout RNTester example for Alerts and LoadingView.
https://github.com/facebook/react-native/assets/52801365/8cf4d698-db6d-4a12-8d8d-7a5acf34858b
Reviewed By: huntie
Differential Revision: D52431720
Pulled By: cipolleschi
fbshipit-source-id: 0d6ef1d46b2428c30c9f64dae66b95dbc69f0a3b
Summary:
This PR resolves the potential problem of misconfiguration of components after being recycled. Some of them have custom, sometimes native (e.g. connected to VCs) logic that messes up with the concept of recycling.
bypass-github-export-checks
## Changelog
Added `shouldBeRecycled` field checking to `RCTComponentViewClassDescriptor `, a check for it in `_enqueueComponentViewWithComponentHandle:(ComponentHandle)componentHandle
componentViewDescriptor:(RCTComponentViewDescriptor)componentViewDescriptor` method, and a default implementation in `RCTComponentViewDescriptor` returning `YES` in order not to change the default behavior.
[iOS] [Added] - Add `shouldBeRecycled` method on `iOS`.
Pull Request resolved: https://github.com/facebook/react-native/pull/35378
Test Plan: Override this method in your custom `componentView` and see that the component is not recycled.
Reviewed By: javache
Differential Revision: D41381683
Pulled By: cipolleschi
fbshipit-source-id: 10fd1e88f99b3608767c0b57fad462837924f02a
Summary:
Bump folly version to 2024.01.01.00. Actually we need a version newer than v2023.08.14.00 with the https://github.com/facebook/folly/commit/c52d4490bf1e0cf117a71342b427984f9ffc316e fix. That will fix build error on Android:
```
In file included from /Users/kudo/expo/expo/node_modules/react-native-reanimated/android/src/main/cpp/NativeProxy.cpp:3:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/jsi/include/jsi/JSIDynamic.h:10:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic.h:1310:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic-inl.h:22:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Conv.h:124:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Demangle.h:19:
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1721:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::equal;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1723:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::less;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1725:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::greater;
~~~~~^
3 errors generated.
```
## Changelog:
[GENERAL] [CHANGED] - Bump folly version to 2024.01.01.00
Pull Request resolved: https://github.com/facebook/react-native/pull/42145
Test Plan: ci passed
Reviewed By: cortinico, cipolleschi
Differential Revision: D52546945
Pulled By: NickGerleman
fbshipit-source-id: 64aacb1d310062dddf987c7b95f10a477e293693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42144
D51895785 changed several CMake libraries from shared to static, including `jsinspector`. This happens to be semantically incorrect in the case of `jsinspector`, as the library contains singletons which can be inadvertently duplicated due to static linking. As a result, different parts of the code can end up accessing different instances of a supposed singleton, leading to bugs.
Here we revert the change to `jsinspector` (only) and add an explanatory comment to signpost this for future readers.
## More context & general principle
While nothing is broken today, allowing static libraries to contain global state is brittle and breaks in surprising ways:
* The upcoming diff D52231237 introduces a new dependency on `jsinspector` which builds cleanly, but causes debugging to stop working because of the duplicated singleton.
* The only reason debugging currently works in the CMake build of Bridgeless is by a happy accident: the shared library `hermesinstancejni` depends on `reactnativejni` through a chain of three other libraries unrelated to debugging, and as a result, can access `reactnativejni`'s copy of `jsinspector` (see graph).
{F1237835169}
It seems that the safest rule of thumb, given the way React Native is currently structured, is that **singletons should live in their own shared libraries** so no call site can cause them to be duplicated through static linking. (It's reasonable to revisit this guidance if we manage to consolidate React Native into one monolithic shared library, eliminating the footgun at the source.)
Changelog:
[Internal] [Changed] - Change jsinspector back to a shared library in the CMake build.
Reviewed By: cortinico, NickGerleman
Differential Revision: D52541488
fbshipit-source-id: 502210add0b734a9bbc470bdf38fb70a41e149a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42136
`Wpedantic` flags usage of variadic macros with zero arguments. This is widely supported by different compilers (including MSVC), but was previously forbidden by the standard.
C++ 20 explicitly allows them, so, theoretically Clang should know not to warn about these now. Let's try that.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52534129
fbshipit-source-id: e27a75081fac6b4196c6dbb5242812877b0bd679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42133
## Changelog:
[General][Fixed] - TouchableBounce, TouchableHighlight and TouchableNativeFeedback dropping touches with React 18.
TouchableBounce, TouchableHighlight and TouchableNativeFeedback do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableBounce, TouchableHighlight and TouchableNativeFeedback were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52514643
fbshipit-source-id: 0d6ae4bb7c2a797cc443181459c5614da0ecfc7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42062
We have had relative as the default for a few big frameworks/apps right now (Fabric FB iOS, Fabric FB Android, OSS, Litho, CK) and have not run into issues. Seems it is safe to pull the trigger here and put everything on relative 🎉
This also fixes a test that relied on this default, changes the layout metrics default, and removes the gating plumbing that was in place earlier.
Lastly, a few animation tests start failing after this change. Seems that there is an animation bug with relative trees that would have existed already, so this is merely discovering that that bug exists, not causing any extra issues. Since that test is a set of random trees with random props it is very hard to debug and I am just adding skips to the failing ones.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52137858
fbshipit-source-id: 6856bc608b8211c868c9ee81fc92e005ec3d2faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42020
I added position type in D51412428 (https://github.com/facebook/react-native/pull/41819). I didn't notice this == override which makes it so position type in layout metrics will not be updated if it changes.
To use this cpp 20 feature we needed to change a few buck files which is also done here
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52339890
fbshipit-source-id: e77ee092477dbf786e4a72e6a33138ccbc450645
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42122
This diff introduces the `TypeUtils` directory where we can put platform-specific, context-independent type transformations.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52291837
fbshipit-source-id: 561b9c494aab5bfee3b3c668d3346bbd320e5266
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42128
Scroll view was not emitting the `onScrollToTop` event when the user tapped on the status bar.
This change fixes this by adding the event to the C++ Event Emitter and by invoking it into the `RCTScrollViewComponentView`
## Changelog
[iOS][Added] - Add onScrollToTop event in Fabric
Reviewed By: sammy-SC
Differential Revision: D52509919
fbshipit-source-id: 7b72c927823fa971be99c4da4b0287d4e23a02b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42127
The current scrollViewExamples does not trigger the OnScrollToTop event.
This change for Paper adds that and refactors the codebase to isolate that example.
## Changelog:
[Internal] - Improve RNTester ScrollView example adding OnScrollView event.
Reviewed By: sammy-SC
Differential Revision: D52509669
fbshipit-source-id: 8fd0fcca7153ba41bf054832928e661ef7dff3fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42113
For easier testing/debugging, log something if bridgeless is enabled for the app. This log will show up only once.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52464640
fbshipit-source-id: 5019a1a6bf4f171a5f1dc4b3b2692db9e07ff43c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42073
This moved various Meta-internal runtime setup off AppDelegate.mm to reduce the #if checks throughout the file.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52424748
fbshipit-source-id: b53799c8bb1544dbbb429cea811861ae52125641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42086
Changelog: [General][Changed] - Update monorepo dependency versions to remove ^
This change will remove the caret for now as we already perform an "align" step everytime we bump a monorepo library. This prevents monorepo library updates to affect existing releases.
The "align" step updates all monorepo libraries to use the updated bumped version: https://fburl.com/code/xfistiph
Reviewed By: huntie
Differential Revision: D52440454
fbshipit-source-id: ff071032f04bc554903dde153c594991163dfe2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42121
## Changelog:
[General][Fixed] - TouchableWithoutFeedback and TouchableOpacity dropping touches with React 18.
TouchableWithoutFeedback and TouchableOpacity do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableWithoutFeedback and TouchableOpacity were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52388699
fbshipit-source-id: ef13194c6581c5d31d0f1cb465bfd0cf98d672ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42090
This change is the last pieces of removing `RCT_NEW_ARCH_ENABLED` flag and defragmenting the build setup on iOS.
Before, 3rd party libraries had to use the `#if RCT_NEW_ARCH_ENABLED` flag to compile in and out segment of code depending on whether the new architecture was turned on or not.
After the recent changes, we can now expose the `RCTIsNewArchEnabled()` function to read whether the New Arch is enabled at runtime or not.
This will promote better code practices as we can replace ugly, compile time, `#if-#else-#endif`s with a more readable and natural regular obj-c code.
We can also use inheritance to have different implementation based on the architecture.
To use the new function, a 3rd party library have to:
1. `#import <React/RCTUtils.h>` (if they use the `install_modules_dependencies` function we provide, they can already do it)
2. invoke `RCTIsNewArchEnabled()` which returns a BOOL.
3. implement the code accordingly, depending on the New arch state.
**Note:** we implemented also the `RCTSetNewArchEnabled` function. This is called as soon as React Native is initialized in the `RCTAppDelegate`. The method can be called only once per React Native lifecycle. Subsequent calls to that method are ignored.
## Changelog:
[iOS][Added] - Added the `RCTIsNewArchEnabled()` to check whether the New Arch is enabled at runtime.
Reviewed By: cortinico
Differential Revision: D52445107
fbshipit-source-id: 1b432832912d33c85687b4c37f9e360ce9699f59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42088
This change adds an extra function to customise the RootView in both Bridge and Bridgeless mode.
To nudge users in a migration, we also add a warning message for next version that should push our users to migrate away from the old implementation to the new one.
*The Warning is shown ONLY when the user do customise the rootView*. For users which were not customising the Root View, the warning will not appear.
The documentation of the new method plus the warning should guide the users toward the right migration path.
## Changelog
[iOS][Added] - Added the customiseRootView method which is called in both bridge and bridgeless. Added also a warning for 0.74 with instructions on how to migrate.
Reviewed By: cortinico
Differential Revision: D52442598
fbshipit-source-id: 8b99b67f4741ee61989a8659a3d74c1eba27bc5b
Luna
Samuel Susla
Moti Zilberman
Kesha Antonov
Alexander Blom
Riccardo Cipolleschi
Kudo Chien
Joe Vilches
fortmarek
William Fernandes
Dr. Sergey Pogodin
Luna Wei
Saad Najmi
Mateusz Wit
Kevin Gozali
Oskar Kwaśniewski
Wojciech Lewicki
Alex Hunt
Dmitry Rykun
Nick Gerleman
Carmi Grushko
Arushi Kesarwani