Summary:
In https://github.com/facebook/react-native/pull/37510, a check was introduced to check if user is using `latest` version of `npx`, but right now it checks for every command executed, but it should only ensure that `latest` is included when creating a new project.
In this Pull Request I've added a condition to only warn if `init` was fired.
## Changelog:
[GENERAL] [FIXED] - Warn only in `init` command when CLI uses cached `npx` version
Pull Request resolved: https://github.com/facebook/react-native/pull/44644
Test Plan: Warning about using `latest` version CLI should only be presented when running `init` command.
Reviewed By: arushikesarwani94
Differential Revision: D57681864
Pulled By: blakef
fbshipit-source-id: 5c81b9a08141396efcd24539b2560cea16028dd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44650
Changelog: [Internal]
Adds the missing `DoNotStrip` annotations to methods of `CxxInspectorPackagerConnection.DelegateImpl` that are called from C++.
Reviewed By: huntie
Differential Revision: D57708376
fbshipit-source-id: 8a72b19211b60ce7a6049079e5ecfc2e96bc974f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44630
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module structs
This changes the names of C++ Turbo Modules structs to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export type ValueStruct = {
x: number,
y: string,
z: ObjectStruct,
};
export interface Spec extends TurboModule {
+getValueStruct: () => ValueStruct
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxValueStruct
^^^
```
Now the generate name is:
```
NativeMyAbcModuleValueStruct
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
## Why?
- The `Cxx` extension is a temporary hint to react-native-codegen to enable extra capabilities and might disappear eventually
- The C++ base struct name should be 'stable'
- The name of the exported TM JS spec `TurboModuleRegistry.get<Spec>(...)` is abritrary, the hasteName is not
- The name of the RN JS TM spec must start with `Native` which better guarantees a consistent naming scheme for these generated base class
- The C++ Turbo Module base class has now the same prefix as the generated structs - `NativeMyAbcModule` for the example above
Reviewed By: cipolleschi
Differential Revision: D57599257
fbshipit-source-id: 4fafe6c7e920737fa766bd7e8e68e521f608e775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44620
We added a log message when trying to lock revisions in `LazyShadowTreeRevisionConsistencyManager` when they were already locked, and we've seen that being logged in existing experiments, which could indicate we're doing re-entrance from the JS runtime.
This protects against that case migrating the boolean flag to an integer.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D57509193
fbshipit-source-id: 1712aa84d665c9dfe50630818e7f56de7d7e145c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44619
Some methods in `LazyShadowTreeRevisionConsistencyManager` can be called in parallel when using synchronous state updates (which is also behind a flag). This implements thread-safety to cover that case so we don't have issues when testing that variant in production.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D57506540
fbshipit-source-id: 362e1df534bc8c87289882236cfe0d7ee261f507
Summary:
Changelog: [Internal]
bypass-github-export-checks
Currently, Hermes never generates object/array previews for values logged via the `console` API. This makes console logs significantly less readable than in Chrome. Here we enable the preview generation machinery that already exists in Hermes.
We conservatively mimic V8's behaviour of [only generating previews for immediately-emitted messages](https://source.chromium.org/chromium/chromium/src/+/main:v8/src/inspector/v8-console-agent-impl.cc;l=53,64;drc=451a101b0a8bbc323dbf5697dd956b55284ec9ee) and not for buffered messages. I don't know *why* V8 does this, but can only guess it's meant to improve the performance of starting a debugging session, by evaluating less code and sending smaller payloads. (Anyway, we can change our decision later.)
Reviewed By: dannysu
Differential Revision: D57617059
fbshipit-source-id: 1f5a71ce98ac915a5b874ed6c009d971405a9f2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44637
Setting the wrong thing to {}. `result` should be set here just like in the other early returns.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57617046
fbshipit-source-id: e47dbdb7821879ffa02d11b7e68eec1c9bfbdefd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44226
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Yet another attempt to land this (last one was D55964787).
Copy-pasting below the amazing summary from RSNara.
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
NOTE: Intentionally not converting `BridgeReactContext` to Kotlin to minimize the risk of these changes.
Reviewed By: cortinico
Differential Revision: D56064036
fbshipit-source-id: 2e380bf7ee46892c5fc0044b03a929f12d122157
Summary:
Goal of this PR is to optimise `Pressable` component, similarly to https://github.com/react-native-tvos/react-native-tvos/pull/724 . `Pressable` `style` and `children` properties can, but doesn't have to be functions. Usually we passing objects or arrays. `pressed` state is used only when `style` or `children` are `functions`, so let's update that state only in such case, otherwise let's skip state updates to improve the performance.
That way we won't have to rerender the component when it is being pressed (assuming that `style` and `children` are not going to be functions)
## Changelog:
[GENERAL] [CHANGED] - Improve performance of `Pressable` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44615
Test Plan: Verify that `Pressable` updates its `pressed` state when `style` or `children` are functions.
Reviewed By: javache
Differential Revision: D57614309
Pulled By: fabriziocucci
fbshipit-source-id: 473e0ab3c4bf7b3ef04ba19f76105ac65371a3fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44582
D54496604 fixed lifecycle methods for JavaTimerManager, which now reveals another bug. Because this codepath ends up creating a `HeadlessJsTaskContext` which in turn creates a `Handler`, ReactInstance destruction doesn't complete cleanly.
```
2024-05-15 17:42:52.935 12681 27113 W fb4a.BridgelessReact: ReactHost{1}.getOrCreateDestroyTask(): React destruction failed. ReactInstance task faulted. Fault reason: Can't create handler inside thread Thread[pool-51-thread-1,5,main] that has not called Looper.prepare(). Destroy reason: FbReactInstanceHolder.destroyReactManager(): FbReactInstanceLogoutCleaner.clearReactInstanceData()
```
The fix is to not create our own Handler, but instead use the shared methods in UiThreadUtil.
Changelog: [Android][Fixed] Fixed error thrown during ReactInstance teardown
Reviewed By: cortinico
Differential Revision: D57378247
fbshipit-source-id: a31dc8e35b5418a71b83c301973f12350f2ee01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44633
`toDynamic` no longer exists for ParagraphState, so try the MapBuffer value first, before triggering the error introduced in D56963463.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57439386
fbshipit-source-id: 31e6466d9dec5b835551cca6c946b28cfbd4578b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44626
This variable is unused and is shadowed by a function local.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57568098
fbshipit-source-id: e5f56b7ef88497d4b9935275eb7e805660741146
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44237
This adds support for color function values to ColorPropConverter per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It updates the color conversion code so that it returns a Color instance before ultimately being converted to an Integer in preparation for returning long values as needed.
## Changelog:
[ANDROID] [ADDED] - Update ColorPropConverter to support color function values
Pull Request resolved: https://github.com/facebook/react-native/pull/43031
Test Plan:
Colors should work exactly the same as before.
Follow test steps from https://github.com/facebook/react-native/pull/42831 to test support for color() function syntax.
While colors specified with color() function syntax will not yet render in DisplayP3 color space they will not be misrecognized as resource path colors but will instead fallback to their sRGB color space values.
---
After the failure with the tests, I reapplied the changes and test some Jest e2e tests that were failing yesterday:
{F1495277376}
Reviewed By: cortinico
Differential Revision: D56517579
Pulled By: cipolleschi
fbshipit-source-id: ae9b5bc2afe9eb9760dd91afb090385daf7102b8
Summary:
D57197676 reordered the TextExample test cases, but accidentally reused the same string as the case in packages/rn-tester/js/examples/Text/TextInlineViewsExample.js
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57279961
fbshipit-source-id: 60a41eaf13d82538ee149fe4ef5531e42c00b012
Summary:
tsia. Done to allow for easier interaction of the examples, especially those with long descriptions
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57278607
fbshipit-source-id: f0a1d06c97c019fe177c8b9e51c3ca0ae12caef5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44552
Changelog: [Android][Fixed] If the RNTester app is started with a deeplink intent, we now correctly navigate there for Android to facilitate e2e testing. This already worked on ios.
Reviewed By: javache
Differential Revision: D54662737
fbshipit-source-id: 5bbf824c80e226f441bdcbc4fa67e41ab4c3eb33
Summary: Changelog: [Android][Added] add FBEndToEndDumpsysHelper stub to RNTester Android to be able to dump ViewHierarcies internally.
Reviewed By: makovkastar
Differential Revision: D54662739
fbshipit-source-id: 5236ae84ed648d431a8f01558f8f84049480ba39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44618
This change is a prerequisite to converting this file to Kotlin. It adds null checks to potentially nullable window and inset getters that were previously not there.
## Changelog:
[Android] [Changed] - Added null checks, marked null safety in StatusBarModule
Reviewed By: NickGerleman
Differential Revision: D57553395
fbshipit-source-id: 5293bb74a95d22bb82971c0a9d691c9e5e36d81f
Summary:
`pod install` and CocoaPods are actually not macOS specific.
Still, the pod lifecycle scripts of `react-native` depend on macOS-only utilities and will fail on Linux.
This is an attempt to make the scripts portable and make the pod install cleanly on Linux as well as macOS.
## Changelog:
[INTERNAL] [FIXED] - Skip XCode patching when not run on macOS
[INTERNAL] [FIXED] - Fall back to `which gcc`/`which g++` to identify C/C++ compiler when `xcrun` not available
[INTERNAL] [FEAT] - Recognize CC and CXX env vars supplied to the script and prefer them over autodetection
Pull Request resolved: https://github.com/facebook/react-native/pull/44417
Reviewed By: NickGerleman
Differential Revision: D57055928
Pulled By: cipolleschi
fbshipit-source-id: 1c49f70c52b4667abf0a215cbee52ee6aa6dd052
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44602
Fix regression caused by D56943825 where radii set to 0 was not being considered. Also preemptively fix a possible bug with RTL due to incorrect overrides.
Changelog:
[Android][Fixed] - Fix borderRadius incorrect overrides
Reviewed By: NickGerleman
Differential Revision: D57473482
fbshipit-source-id: d22a46bdd271d5f254e7d7e54abc55c00a8da8f2
Summary:
Apple is enforcing that new apps submission to the store mst use XCode 15. There is no reason to keep testing on Xcode 14.3 anymore, hence we are removing those jobs.
While doing that, we are also aligning the tests between Test_All and test_iOS workflows.
bypass-github-export-checks
## Changelog:
[Internal] - Remove CircleCI tests for Xcode 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/44448
Test Plan: CircleCI must stay Green
Reviewed By: huntie
Differential Revision: D57153939
Pulled By: cipolleschi
fbshipit-source-id: 82278bcb598b134238852e32b667a28619fb74cb
Summary:
One of the last parts of the migration. This PR foucuses on bringing the template jobs to Github actions.
bypass-github-export-checks
## Changelog:
[Internal] - Migrate template jobs from CCI to GH
Pull Request resolved: https://github.com/facebook/react-native/pull/44511
Test Plan: https://fburl.com/workplace/f6mz6tmw
Reviewed By: blakef
Differential Revision: D57202477
Pulled By: cipolleschi
fbshipit-source-id: be562cd3690d221f094dc734dd501aac25c36f59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44613
We are building a native CSS parser for Fabric, to allow broader support for CSS. One area not yet implemented are features required for color.
<hash-token> is a pre-requisite.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57180293
fbshipit-source-id: 0932c44d881f205aed55bcdf4fa23ad04b336c11
Summary:
Right now we use layout direction determined by I18NManager to influence the root Yoga layout direction.
Individual views may have a different resolved layout direction (e.g. due to `direction` style prop), and even though we don't rely on Android layout props, Android components still need to inherit or know the right layout direction to still do correct drawing. Example of this was scrollbar showing up on the left, instead of right in RTL, as soon as ScrollView knew it was in RTL.
This has potential to change a good amount of behavior, so this is under QE.
Changelog:
[Android][Fixed] - Propagate layout direction to Android Views and Drawables
Reviewed By: joevilches
Differential Revision: D57248417
fbshipit-source-id: 4bcdf2b23277ff926a796b8377df08d49c7b914c
Summary:
D57285584 was reverted because we have service code with a faulty measure function, and adding logging to Yoga when invalid measurements were received was enough to spike error rate to elevated levels and block release.
This is a reland of the below change, with a couple modifications:
1. We log warnings instead of errors, which from what I heard, shouldn't block release, but should still make signal
2. We only zero the dimension which was NaN, to preserve exact behavior
## Original
We've started seeing assertion failures in Yoga where a `NaN` value makes its way to an `availableHeight` constraint when measuring Litho tree.
Because it's only happening on Litho, I have some suspicion this might be originating from a Litho-specific measure function. This adds sanitization in Yoga to measure function results, where we will log an error, and set size to zero, if either dimension ends up being negative of `NaN`.
This doesn't really help track down where the error was happening, but Yoga doesn't have great context to show this to begin with. If we see this is issue, next steps would be Litho internal intrumentation to find culprit.
Changelog: [Internal]
Reviewed By: sbuggay
Differential Revision: D57473295
fbshipit-source-id: 979f1b9a51f5550a8d3ca534276ec191a3cb7b9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44600
I didn't pay close enough attention during merge between V1 and V2 of D57248205, and what I ultimately checked in is not correct. Fix the logic here.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D57488372
fbshipit-source-id: c9db597a6ae4ca5ae81e6ccd9913a14be268dd57
Summary:
This PR adds percentage support in translate properties for new arch iOS. Isolating this PR for easier reviews.
The approach taken here introduces usage of `ValueUnit` struct for transform operations so it can support `%` in translates and delay the generation of actual transform matrix until view dimensions are known. I have tried to keep the changes minimal and reuse existing APIs, open to changes if there's an alternative approach.
## Changelog:
[IOS] [ADDED] - Percentage support in translate in new arch.
<!-- 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/43192
Test Plan:
- Checkout TransformExample.js -> Translate percentage example.
- Added a simple test in `processTransform-test.js`. The regex is not perfect (values like 20px%, 20%px will pass, can be improved, let me know!)
Related PRs - https://github.com/facebook/react-native/pull/43193, https://github.com/facebook/react-native/pull/43191
Reviewed By: javache
Differential Revision: D56802425
Pulled By: NickGerleman
fbshipit-source-id: 978cbbdde004afe1e68ffee9a3c7eb7d16336b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44538
Android originated without RTL support. When RTL support was added, Applications needed to set `android:supportsRtl="true"` in their manifest, to allow Android to do RTL specific layout and drawing. This became the default for new projects created by Android Studio at some point.
React Native was not setting this in template, which means apps created from it do not do any of Android's RTL layout, text alignment, or drawing (e.g. in D3652980 8 years ago, a native drawer component came from the wrong side of the screen). RN would still layout the app using Yoga in RTL if in RTL locale though.
This change sets `android:supportsRtl` in template matching default new Android projects, and to avoid mismatched states in the future, will only tell I18NManager that RTL is allowed if `android:supportsRtl` is also set. This is breaking, since existing apps may not get Yoga RTL support unless telling Android that the application should support RTL layout.
Changelog:
[Android][Breaking] - Set and require `android:supportsRtl="true"` for RTL layout
Reviewed By: joevilches
Differential Revision: D57248205
fbshipit-source-id: 3f60c9f855db26f8d34a2e05d460f95961f5ffeb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44561
D57089275 introduced a layer to parse component values out of the token stream. I modeled this similar to the tokenizer, as a flat iterator of component values. Because function components can nest a variable number of child component values, this now looks like storing a fully resolved tree of tokens on the heap during parsing.
This diff changes the model, so that `CSSSyntaxParser::consumeComponentValue()` no longer returns a resolved CSS function value. Instead, users of the parser are expected to provide "visitors" which continue parsing, matched based on component value type pattern matched. Visitors can perform parsing specific to their context, and propagate values up the stack, based on their evaluation of the component value.
Removing the heap allocated list of tokens here also lets this core CSS parsing stack keep constexpr, so I added that back, though we need to keep expression trees for math expressions in uncommon cases, so the layer up probaly won't keep constexpr.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57206706
fbshipit-source-id: 25db84d376ef18f6291e60ed953e29c4000a7a26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44546
# Changelog:
[Internal] -
This is the first chunk of moving all of the interfaces to Kotlin inside `react.bridge`, covering the small-ish (functional/SAM and such) interfaces.
Reviewed By: javache
Differential Revision: D57253634
fbshipit-source-id: aa26d26b9681ac7c6059c249b985ff5121ad1e9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44583
This native module is only available in the new architecture, stub the methods elsewhere.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D57382785
fbshipit-source-id: f6c988bcfd12633697b45a1f862b2cd4fb5d00d4
Summary:
Currently RCTPerfMonitor won't show up in scene based app, we should first try to extract the window from the connected scenes, and fallback to the window in `UIApplicationDelegate`.
## 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 RCTPerfMonitor not showing up in scene based app
Pull Request resolved: https://github.com/facebook/react-native/pull/43476
Test Plan:
- Tested RCTPerfMonitor in app not using scenes;
- Tested RCTPerfMonitor in app using scenes in iOS 13 & 14;
- Tested RCTPerfMonitor in app using scenes in iOS 15+.
Reviewed By: rshest
Differential Revision: D57381551
Pulled By: javache
fbshipit-source-id: fd6cce20c9a4ed41d7aae84751fc0c83391d0865