Summary:
This PR extracts the `findComponentConfig(...)` Flow and TS from the `index.js`'s files to the `parser-commons.js` file.
bypass-github-export-checks
## Changelog:
[INTERNAL][CHANGED] - Refactor: Extract `findComponentConfig(...)` from Flow & TS to `parsers-commons.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/37547
Test Plan: - `yarn flow && yarn test packages/react-native-codegen` → should be green.
Reviewed By: cortinico
Differential Revision: D46143481
Pulled By: cipolleschi
fbshipit-source-id: f9a456b1d58312422b17463ed2b60ee5fda16462
Summary:
[Codegen 87] This PR introduces `getProps` to the Parser class and implements this function in Typescript and Flow Parsers.
We also get rid of the following files from :
- `packages/react-native-codegen/src/parsers/typescript/components/props.js`
- `packages/react-native-codegen/src/parsers/flow/components/props.js`
as requested on https://github.com/facebook/react-native/issues/34872
bypass-github-export-checks
## Changelog:
[Internal] [Changed] - Add `getProps ` to Parsers and update usages.
Pull Request resolved: https://github.com/facebook/react-native/pull/37504
Test Plan: Run yarn jest react-native-codegen and ensure CI is green
Reviewed By: cortinico
Differential Revision: D46074152
Pulled By: cipolleschi
fbshipit-source-id: aa6a1a556c9b4a4a6209221f70c8add46ed2d08b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37567
Changelog: [Internal]
in the situation where we want to refresh the bundle url due to developer mode, we add a private API that allows the host to refresh its bundle URL if needed. this private API will be called on cmd + R, which is the only case that supports the changing bundle URL in the middle of the app session.
Reviewed By: cipolleschi
Differential Revision: D45937856
fbshipit-source-id: 718047abcbce983c4f820eb550d6fce05d03bfee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37568
Changelog: [Internal]
since bundleURL is constant throughout an app session, we should pass it in as a dependency from above. in the next diff, i'll get rid of `getBundleURL` from the react host's delegate.
Reviewed By: sammy-SC
Differential Revision: D45937855
fbshipit-source-id: 6306407f25c0f3eb8547e6aaf6e10ed9d2fddeaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37566
Changelog: [Internal]
in this diff stack, i remove `- (NSURL *)getBundleURL;` from the bridgeless API.
the reason for this is because the bundle url does not change in the middle of an app session, unless for developer mode, so it's more robust for us to pass it as a dependency.
at the end of the diff stack, i'll add an escape hatch that allows us to update the bundle url for our dev mode case, so we can delete the API.
in this diff, i do some cleanup so the bundle logic is more reusable.
Reviewed By: sammy-SC
Differential Revision: D45937853
fbshipit-source-id: e80bacfa7342f63caa020e4a00750ffa156bf8e7
Summary:
Currently when using a TextInput with a controlled selection prop the Copy / Paste menu is constantly getting dismissed and is impossible to use. This is because Android dismisses it when certain method that affect the input text are called (https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/java/android/widget/Editor.java;l=1667;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176?q=Editor, https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/java/android/widget/TextView.java;l=6792;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176). The solution to fix this is to avoid calling those methods when only the selection changes.
I also noticed there are a lot of differences on how selection is handled in old vs new arch and a lot of the selection handling can actually be removed as it is partially the cause of this issue.
This implements 2 mitigations to avoid the issue:
- Unify selection handling via commands for old arch, like fabric. Selection is currently a prop in the native component, but it is completely ignored in fabric and selection is set using commands. I removed the selection prop from the native component on Android so now it is exclusively handled with commands like it is currently for fabric. This makes it so that when the selection prop changes the native component no longer re-renders which helps mitigate this issue. More specifically for the old arch we no longer handle the `selection` prop in `ReactTextInputShadowNode`, which used to invalidate the shadow node and cause the text to be replaced and the copy / paste menu to close.
- Only set placeholder if the text value changed. Calling `EditText.setHint` also causes the copy / paste menu to be dismissed. Fabric will call all props handlers when a single prop changed, so if the `selection` prop changed the `placeholder` prop handler would be called too. To fix this we can check that the value changed before calling `setHint`.
## Changelog:
[ANDROID] [FIXED] - Fix copy / paste menu and simplify controlled text selection on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/37424
Test Plan:
Tested on new and old arch in RNTester example.
Before:
https://github.com/facebook/react-native/assets/2677334/a915b62a-dd79-4adb-9d95-2317780431cf
After:
https://github.com/facebook/react-native/assets/2677334/0dd475ed-8981-410c-8908-f00998dcc425
Reviewed By: cortinico
Differential Revision: D45958425
Pulled By: NickGerleman
fbshipit-source-id: 7b90c1270274f6621303efa60b5398b1a49276ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37542
Changelog: [General] [Changed] - Pressable: prevent click bubbling in Pressable
This diff modifies pressability such that `onClick` events for pressables will only result in `onPress` being called when the pressable in question is both the `target` and the `currentTarget` for the event.
This is only really relevant for nested pressables, where `click` received by the inner pressable may bubble up to the parent pressable (this change effectively prevents that from happening). A future change will update the click event on Android to be bubbling (currently its a direct event); this change will reduce the possibility of breakages from that change.
Reviewed By: vincentriemer
Differential Revision: D46081810
fbshipit-source-id: 37423fda03992d48baee04b753d7bb9295a76f9b
Summary:
The throttling mechanism for fallbacks should apply to both their
appearance _and_ disappearance.
This was mostly addressed by #26611. See that PR for additional context.
However, a flaw in the implementation is that we only update the the
timestamp used for throttling when the fallback initially appears. We
don't update it when the real content pops in. If lots of content in
separate Suspense trees loads around the same time, you can still get
jank.
The issue is fixed by updating the throttling timestamp whenever the
visibility of a fallback changes. Not just when it appears.
DiffTrain build for commit https://github.com/facebook/react/commit/4bfcd02b2cebcb390f5aff0d7747c60a55012d5d.
Reviewed By: hoxyq
Differential Revision: D45920350
Pulled By: sammy-SC
fbshipit-source-id: f5df1709a66e8014d4458fdfdf960d58e0acc45f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37555
Changelog: [Internal] Refactor some npm commands and centralize in npm-utils.
For now, centralize `getPackageVersionStrByTag` and `publishPackage` and update:
1. `publish-npm` to use utilities. This is how we publish `react-native` for commitlies, releases, and nightlies
2. Update `find-and-publish-all-bumped-packages.js` where we publish our monorepo dependencies
Reviewed By: cortinico, hoxyq
Differential Revision: D46131120
fbshipit-source-id: e6020058eb94b4f8d95068b8cd87cc765711be5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37540
Changelog: [Internal] [Added] - W3CPointerEvents: add basic testbed for click event accessibility
This change adds a test bed with some nested pressables/clickable views. We can use this to test behavior for accessibility clicks on nested pressables (a corner case), and this can be expanded for other a11y testing in the future.
Reviewed By: NickGerleman
Differential Revision: D46081730
fbshipit-source-id: 6a9e1d52b2d8824cd61cb32dd0da435499c4ef29
Summary:
Avoid using the install target in Hermes when building frameworks for Apple platforms. Instead, explicitly build the targets we need for each platform, and copy over the files we need. This has a few advantages:
1. It gives RN fine control over the organisation of files in the destroot directory.
2. The current install target seems to copy JSI headers from Hermes instead of the supplied `JSI_DIR`. In practice, this should never be a problem but it is good to be consistent.
3. Building the install target needlessly builds unrelated targets. This slows down the build, and in some cases, we may not technically support those targets for the platform we are building for.
Pull Request resolved: https://github.com/facebook/react-native/pull/37498
Test Plan:
CI is able to build and use Hermes
## Changelog:
[Internal]
Reviewed By: dmytrorykun
Differential Revision: D46097200
Pulled By: neildhar
fbshipit-source-id: 9630b0058f770b6a03aea51622cc6e5b2f8e217e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37512
Rolling this out allows us to enable the asserts in Scheduler and SurfaceHandler again, which validate the correctness of our teardown routines.
Changelog: [Android][Fixed] When applications reload, the previous react root will be correctly closed
Reviewed By: NickGerleman
Differential Revision: D45905628
fbshipit-source-id: 446804c04290a799c38e4d64fb7b6be1d96e8dd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37550
RN Tester is instacrashing on Android on main sadly since a while.
I've noticed it while working on another diff. The crash is a native crash with message:
```
Abort message: 'terminating with uncaught exception of type facebook::jni::JniException: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/fabric/events/EventEmitterWrapper;.<init>(Lcom/facebook/jni/HybridData;)V"'
```
which happens because this method is stripped by proguard. I'm fixing it here.
Changelog:
[Android] [Fixed] - Fix instacrash on main for Release due to java.lang.NoSuchMethodError
Reviewed By: cipolleschi
Differential Revision: D46145613
fbshipit-source-id: 4716458e80fefad5eb9a29a06740134b480e1cd7
Summary:
Currently we do _not_ greet; **"First Time Contributors"**.
It is important to greet every first time contributor keep the OSS community thriving. 😊
This PR; Adds a greet action `greet.yml` 🎉, which comments under First Time Contributors PRs, greeting them as well suggesting some basic steps/guidelines.
## Changelog:
[GENERAL] [ADDED] - [Actions] Add greet action 🎉
Pull Request resolved: https://github.com/facebook/react-native/pull/37499
Test Plan: - Should greet 1st time contributors
Reviewed By: cortinico
Differential Revision: D46142126
Pulled By: cipolleschi
fbshipit-source-id: 5a619a485409fda6fe895feffb736e878fb206ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37538
Changelog: [Internal] - W3CPointerEvents: add tests for click event
We don't have any existing tests which exercise the new (PointerEvent-based) click events. This change adds 3 tests:
1. PointerEventClickTouch: checks that the click event fires on an element when it is touched and released, and verifies that the event properties have the expected values
2. PointerEventClickTouchHierarchy: checks that the click event fires appropriately in a hierarchy of elements when the initial target of the touch is not the same as the final target (i.e. where the touch is released)
3. PointerEventClickTouchHierarchyPointerEvents: checks that the click event respects the setting of `pointerEvents` property in a hierarchy of elements
Note: these tests currently fail (at least on Android); future changes will bring the functionality in line with test expectations.
Reviewed By: vincentriemer
Differential Revision: D45121367
fbshipit-source-id: 7f22ea582e2568c418f569b7e1139388593574ab
Summary:
Previously, we'd call and use getSnapshot on the second render resulting
in `Warning: Text content did not match. Server: "Nay!" Client: "Yay!"`
and then `Error: Text content does not match server-rendered HTML.`.
Fixes#26095. Closes#26113. Closes#25650.
---------
DiffTrain build for commit https://github.com/facebook/react/commit/4cd7065665ea2cf33c306265c8d817904bb401ca.
Reviewed By: mofeiZ
Differential Revision: D45829972
Pulled By: sammy-SC
fbshipit-source-id: e89404c53a1b8478d22252ca24ddcc9647744d37
Co-authored-by: eps1lon <silbermann.sebastian@gmail.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37501
This is the iOS side of the fix for https://github.com/facebook/react-native/issues/36794.
That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction).
Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](https://github.com/react-native-community/discussions-and-proposals/pull/646) to pass to the JS engine, even where the request URL isn't JSC-safe.
We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too).
For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment.
For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first.
Changelog:
[iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL
Reviewed By: huntie
Differential Revision: D45950661
fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d
Summary:
We've been encountering a crash in `runAnimationStep` with "Calculated frame index should never be lower than 0" https://github.com/facebook/react-native/issues/35766 with OnePlus/Oppo devices as well, but don't have one on hand to test.
This just works around the issue: if the time is before the start time of an animation, we shouldn't do anything anyways, so we just log a message instead of throwing while in production. We still throw in debug mode though for easier debugging.
### Hypothesis of the root cause
Based on stacktrace in https://github.com/facebook/react-native/issues/35766 (which is the same one we see)
Normally, this should happen
1. Choreographer.java constructs a FrameDisplayEventReceiver
2. FrameDisplayEventReceiver.onVSync gets called, which sets the `mTimestampNanos`
3. FrameDisplayEventReceiver.run gets called, which then eventually calls our `doFrame` callback with `mTimestampNanos`. This then causes `FrameBasedAnimationDriver.runAnimationStep` to be called with the same timestamp
I suspect what's happening on OnePlus devices is that the `onVSync` call either doesn't happen or happens rarely enough that the `mTimestampNanos` when `run` is called is sometime in the past
### Fix
1. Add logging so we get the parameters to debug more if we end up getting this error
2. In production, just ignore past times instead of throwing an Error
## Changelog:
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Prevent crash on OnePlus/Oppo devices in runAnimationStep
Pull Request resolved: https://github.com/facebook/react-native/pull/37487
Test Plan: Ran our app using patched version and verified no issues showed up when using it
Reviewed By: cipolleschi
Differential Revision: D46102968
Pulled By: cortinico
fbshipit-source-id: bcb36a0c2aed0afdb8e7e68b141a3db4eb02695a
Summary:
Limit diagnostics width output by `hermesc` as they may cause slowdowns or even crashes in Gradle/Xcode when a minified bundle is used as input. This occurs because Hermes is unable to determine the terminal width when executed by Gradle/Xcode, and falls back to "unlimited". If the input is a minified bundle, Hermes will output the whole bundle for each warning.
See issues filed:
- https://github.com/microsoft/rnx-kit/issues/2416
- https://github.com/microsoft/rnx-kit/issues/2419
- https://github.com/microsoft/rnx-kit/issues/2424
## Changelog:
[GENERAL] [FIXED] - Limit diagnostics width output by `hermesc`
Pull Request resolved: https://github.com/facebook/react-native/pull/37531
Test Plan: See listed issues for repros.
Reviewed By: cipolleschi
Differential Revision: D46102686
Pulled By: cortinico
fbshipit-source-id: 1b821cad7ef0d561a5e1c13a7aedf9b10164620a
Summary:
https://github.com/facebook/react-native/pull/19687https://developer.apple.com/forums/thread/711413
When system version is lower than `iOS 16`, it does not support `dictation` and `keyboard` working at the same time, so if we modify the text, the system will immediately interrupt the `dictation`, so we need to prohibit modification of the text during `recording` and `recognition`
When system version is higher than `iOS 16`, `dictation` and `keyboard` can work at the same time, so `textInputMode.primaryLanguage` is no longer changed to `dictation`, so we can modify the text during `recording`, because the system will not interrupt, but we cannot modify the text during `recognition`, Because the system will temporarily add a `_UITextPlaceholderAttachment` to display the recognition `UIActivityIndicator`
## 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] - Adapt iOS16+ dictation judge condition
Pull Request resolved: https://github.com/facebook/react-native/pull/37188
Test Plan:
Test Code
```javascript
constructor(props) {
super(props)
this.state = {
value: '',
logList: [],
}
}
render() {
return (
<View style={{ flex: 1, padding: 50, backgroundColor: 'white'}}>
<TextInput
style={{ marginTop: 20, height: 50, borderWidth: 1, borderColor: 'black' }}
placeholder={'please input'}
placeholderTextColor={'gray'}
value={this.state.value}
onChangeText={value => {
let logList = this.state.logList
logList.push(value.length <= 0 ? 'null' : value.replace(/\uFFFC/g, '_uFFFC'))
this.setState({ value, logList })
}}
onEndEditing={() => this.setState({ value: '', logList: [] })}
/>
<FlatList
style={{ marginTop: 20, maxHeight: 300, borderWidth: 1, borderColor: 'black' }}
data={this.state.logList}
renderItem={({item}) => (
<Text>{item}</Text>
)}
/>
</View>
)
}
```
Case A: Required < iOS16
1. ensure that https://github.com/facebook/react-native/issues/18890 can work well and dictation will not be interrupted immediately
https://github.com/facebook/react-native/assets/20135674/e69a609c-2dc4-48fc-8186-f9e5af3ac879
Case B: Required >= iOS16
1. ensure that https://github.com/facebook/react-native/issues/18890 can work well and dictation will not be interrupted immediately
https://github.com/facebook/react-native/assets/20135674/caa97e18-c7c4-4a08-9872-b50130f73bf4
Case C: Required >= iOS16
1. start dictation
3. then do not speak any words
4. then end dictation
5. verify that `onChangeText` will callback "\uFFFC" once
6. and then verify `onChangeText` callback an empty string "" once
https://user-images.githubusercontent.com/20135674/235960378-90155ec5-a129-47bc-825b-ee6cb03e7286.MP4
Case D: Required >= iOS16
1. start dictation
3. input some text while speaking some words
4. then end dictation
5. and verify that the `onChangeText` callback work fine.
https://user-images.githubusercontent.com/20135674/235960411-e479d9ab-856a-4407-a644-986426825133.MP4
Case E: Required >= iOS16
1. start dictation
2. say a word
3. and then switch the keyboard to other language
4. verify that dictation will not end
6. continue say some word
8. verify the `onChangeText` callback work fine.
https://user-images.githubusercontent.com/20135674/235960450-351f1aaf-80c0-4d1c-b5c9-3e2cd7225875.MP4
Reviewed By: sammy-SC
Differential Revision: D45563187
Pulled By: dmytrorykun
fbshipit-source-id: 7467b313769896140434f60dcb3590d0b3c1aa15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37452Fixes#37428
We do have cache poisoning for hermesc on Windows and Linux due to reusing the same cache key among different
React Native version. This fixes it by specifying a cache key which is version dependent + it invalidates the
caches by defining a new key.
Changelog:
[Internal] [Fixed] - Make CircleCI caches for hermesc be version dependent
Reviewed By: cortinico
Differential Revision: D45909178
fbshipit-source-id: 830c87ae45739c7053342a68dac2ee7581945c1d
Summary:
## Summary:
This PR fixes a kernel crash caused by trying to blur greyscale images, as described in this issue:
https://github.com/facebook/react-native/issues/35706#issuecomment-1513359724
## Context:
The CGImageGetBitsPerPixel(imageRef) == 8 expression checks if each pixel of the image is represented by 8 bits.
In an image, each pixel is typically represented by a certain amount of information to store its color. In a grayscale image, for instance, we often use 8 bits per pixel, which allows for 256 different shades of gray (2^8 = 256).
The function vImageBoxConvolve_ARGB8888 works with ARGB images (which stands for Alpha, Red, Green, Blue). If the image is only black & white, it means it's a grayscale image, and hence, it is not compatible with this function, causing the kernel crash.
To prevent the issue, we should also convert grayscale images to ARGB before processing them.
## Changelog:
[IOS] [FIXED] - Fix RCTImageBlurUtils.m Greyscale Crash
Pull Request resolved: https://github.com/facebook/react-native/pull/37508
Test Plan:
```
<ImageBackground
blurRadius={18}
source={{uri: 'https://i.scdn.co/image/ab67616d0000b2737663b2f75fe4d8fb2cac8c27'}}
/>
<ImageBackground
blurRadius={5}
source={{uri: 'https://i.scdn.co/image/ab67616d0000b273d5a219b270d74a266131df18'}}
/>
``
Reviewed By: NickGerleman
Differential Revision: D46071330
Pulled By: javache
fbshipit-source-id: 8c04cbf88d467596c9c8a9de9a380bc10663a0e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37471
## Changes
Make the TurboModule system use NativeMethodCallInvoker::invokeSync to schedule synchronous native module method calls. Functionally, this changes nothing.
## What this unlocks
In the future (i.e: D45924977), the TurboModule interop layer will implement NativeMethodCallInvoker::invokeSync to dispatch the constantsToExport method call on to the main queue, when the legacy module requires main queue setup.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D45924976
fbshipit-source-id: 0760827ab3ed72c2f3af0da4e4f2af0e39b639cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37473
## Context
The TurboModule system uses a CallInvoker interface to schedule JavaScript → native, and native → JavaScript calls.
## Problem
JavaScript → native and native → JavaScript calls are different. They can have different behaviours/properties. And, in the future, we might want to evolve them differently. e.g:
- JavaScript → native **always** have a method name. Native → JavaScript calls don't.
- Native → JavaScript can have priorities, since D41492849. JavaScript → native don't.
## Changes
Instead of tying both types of calls to the CallInvoker abstraction, this diff creates a **separate** abstraction for Native → JavaScript calls: NativeMethodCallInvoker.
This way, we can evolve both abstractions separately over time:
- We can evolve the CallInvoker abstraction to suit the needs of JavaScript → native calls.
- We can evolve the NativeMethodCallInvoker abstraction to suite the needs of native → JavaScript calls.
This ultimately makes TurboModule system more extensible.
## Motivation
For the TurboModule interop layer on iOS, React Native needs to execute the "constantsToExport" method on the main queue, when the module requires main queue setup. (implementation: D45924977).
The simplest way to implement this behaviour is to introduce a `methodName` to CallInvoker, and customize the legacy module's CallInvoker::invokeSync method, like so:
```
void invokeSync(std::string methodName, std::function<void()> &&work) override
{
if (requiresMainQueueSetup_ && methodName == "getConstants") {
__block auto retainedWork = std::move(work);
RCTUnsafeExecuteOnMainQueueSync(^{
retainedWork();
});
return;
}
work();
}
```
But, customizing CallInvoker to introduce a `methodName` parameter doesn't make sense: Native → JavaScript calls don't necessarily have method names. So, this diff forks CallInvoker into NativeMethodCallInvoker. That way, we can customize NativeMethodCallInvoker to introduce a method name (which does make sense) and resolve this problem. For the full solution, see D45924977.
NOTE: Now that NativeMethodCallInvoker is different from CallInvoker, it might make sense to re-name CallInvoker back to JSCallInvoker.
Changelog:
[Category][Breaking] - Introduce NativeMethodCallInvoker to replace the TurboModule system's native CallInvoker
Reviewed By: javache
Differential Revision: D45891627
fbshipit-source-id: 39c3f450a290ad396b715288a50858d33ce78441
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37520
Results in better error messages, especially when trying to copy a Value.
With this change:
```
../API/hermes/hermes.cpp: In member function ‘facebook::jsi::Value facebook::hermes::HermesRuntimeImpl::valueFromHermesValue(hermes::vm::HermesValue)’:
../API/hermes/hermes.cpp:726:31: error: use of deleted function ‘facebook::jsi::Value::Value(const facebook::jsi::Value&)’
726 | auto copy = jsi::Value(val);
| ^
In file included from ../API/hermes/hermes.h:18,
from ../API/hermes/hermes.cpp:8:
../API/jsi/jsi/jsi.h:938:18: note: ‘facebook::jsi::Value::Value(const facebook::jsi::Value&)’ is implicitly declared as deleted because ‘facebook::jsi::Value’ declares a move constructor or move assignment operator
938 | class JSI_EXPORT Value {
| ^~~~~
```
Before:
```
In file included from ../API/hermes/hermes.h:18,
from ../API/hermes/hermes.cpp:8:
../API/jsi/jsi/jsi.h: In instantiation of ‘facebook::jsi::Value::Value(T&&) [with T = facebook::jsi::Value&]’:
../API/hermes/hermes.cpp:726:31: required from here
../API/jsi/jsi/jsi.h:963:49: error: no matching function for call to ‘facebook::jsi::Value::kindOf(facebook::jsi::Value&)’
963 | /* implicit */ Value(T&& other) : Value(kindOf(other)) {
| ~~~~~~^~~~~~~
../API/jsi/jsi/jsi.h:1176:30: note: candidate: ‘static constexpr facebook::jsi::Value::ValueKind facebook::jsi::Value::kindOf(const facebook::jsi::Symbol&)’
1176 | constexpr static ValueKind kindOf(const Symbol&) {
| ^~~~~~
../API/jsi/jsi/jsi.h:1176:37: note: no known conversion for argument 1 from ‘facebook::jsi::Value’ to ‘const facebook::jsi::Symbol&’
1176 | constexpr static ValueKind kindOf(const Symbol&) {
| ^~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:1179:30: note: candidate: ‘static constexpr facebook::jsi::Value::ValueKind facebook::jsi::Value::kindOf(const facebook::jsi::String&)’
1179 | constexpr static ValueKind kindOf(const String&) {
| ^~~~~~
../API/jsi/jsi/jsi.h:1179:37: note: no known conversion for argument 1 from ‘facebook::jsi::Value’ to ‘const facebook::jsi::String&’
1179 | constexpr static ValueKind kindOf(const String&) {
| ^~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:1182:30: note: candidate: ‘static constexpr facebook::jsi::Value::ValueKind facebook::jsi::Value::kindOf(const facebook::jsi::Object&)’
1182 | constexpr static ValueKind kindOf(const Object&) {
| ^~~~~~
../API/jsi/jsi/jsi.h:1182:37: note: no known conversion for argument 1 from ‘facebook::jsi::Value’ to ‘const facebook::jsi::Object&’
1182 | constexpr static ValueKind kindOf(const Object&) {
| ^~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:966:47: error: static assertion failed: Value cannot be implicitly move-constructed from this type
965 | std::is_base_of<Symbol, T>::value ||
| ~~~~~~~~
966 | std::is_base_of<String, T>::value ||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
967 | std::is_base_of<Object, T>::value,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../API/jsi/jsi/jsi.h:966:47: note: ‘((((bool)std::integral_constant<bool, false>::value) || ((bool)std::integral_constant<bool, false>::value)) || ((bool)std::integral_constant<bool, false>::value))’ evaluates to false
../API/jsi/jsi/jsi.h:969:5: error: new cannot be applied to a reference type
969 | new (&data_.pointer) T(std::move(other));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Among other things, this puts the actual error on the consuming code where the
error is, which results in those nice red squiggles under it while typing to
tell you that you screwed up.
X-link: https://github.com/facebook/hermes/pull/526
Test Plan: This should only convert one type of compiler error to another, so existing tests should be sufficient.
Reviewed By: tmikov
Differential Revision: D46005344
Pulled By: neildhar
fbshipit-source-id: 194e0483177770df578cb864281d66c88d4cdb7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37519
While these tests currently happen to pass, actually trying to
instantiate `fromJs` fails to compile. I suspect this is attributable
to some difference in how `fromJs` is instantiated in evaluated and
unevaluated contexts. That is since `supportsFromJs` only instantiates
it in an unevaluated context (in a decltype), the rules are presumably
different.
It is also worth noting that the operator of up-casting JSI types to
`jsi::Value` is explicitly deleted in `Converter`, which suggests
that the conversion this test is checking for may be intentionally
unsupported.
For now, since `fromJs` cannot actually be used with the given
parameters, delete the test.
This unblocks a later diff which changes the constructor of
`jsi::Value` such that
`std::is_convertible<jsi::Object &, jsi::Value>` is no longer true (the
conversion is never allowed, but is currently enforced by
`static_assert` ). With that change
`supportsFromJs<jsi::Value, jsi::Object>` also becomes false.
Changelog: [Internal]
Reviewed By: javache, cortinico
Differential Revision: D46059603
fbshipit-source-id: 01ede3cadb74ce6a3cd9d5d3ce34b8648fd88de7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37517Fixes#35778
We got reports of regressions on `useEffect` starting from 0.69+ when on Hermes.
The issue seems to be caused by a bump of the `scheduler` package from 0.20 to 0.21.
In scheduler@0.21, the method `setImmediate` gets called if available
(see https://github.com/facebook/react/pull/20834). This causes React Native to use Microtasks
which ends up in changing the semantic of useEffect.
The solution is to use the Native RuntimeScheduler properly.
On Paper specifically, we never initialized it as it's effectively initialized by the
TurboModuleManagerDelegate. Here I trigger the initialization of it on Paper as well.
Changelog:
[Android] [Fixed] - Make sure the Native RuntimeScheduler is initialized on Old Arch
Reviewed By: sammy-SC
Differential Revision: D46024807
fbshipit-source-id: d72cd774df58410467644cddeaaf37e3c227b505
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37516
This will fail build failures from apps which are using libraries which imports
```
#include <react/renderer/graphics/conversions.h>
```
That's just a warning but our usage of `-Wall -Werror` is causing this to fail user builds.
More context on this issue here:
https://github.com/reactwg/react-native-releases/discussions/54#discussioncomment-5968545
We can revert this `-Wno-error` once we're on 0.73 as that specific #warning will be entirely
removed from the codebase.
Changelog:
[Internal] [Changed] - Add -Wno-error=cpp on App's default Cmake file
Reviewed By: dmytrorykun
Differential Revision: D46071400
fbshipit-source-id: 4937fb1255df3f2765f645dfd59f5c58526dee42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37513
After the monorepo migration, we started to add license headers to the template file.
This needs to be reverted, I'm doing it here.
Changelog:
[Internal] [Changed] - Do not add Meta's license header to template
Reviewed By: dmytrorykun
Differential Revision: D46070682
fbshipit-source-id: ee071d90c92e32c57698b09298a2f5cf39d3f6d7
Summary:
Currently npx has a variety of caching strategies to avoid having to pull a version of the package from a registry. These are often unexpected to our users, who may fall behind. After looking at a variety of fancy approaches to dealing with this (the high end of which was intelligently forking npx to run `npx react-native@latest <args>`, the best possible tradeoff for time and simplicity was to warn the user when they weren't running the latest release:
{F999520817}
### Problem Details
On my laptop when you run `npx <package> <arguments>` this it eventually calls [libnpmexec](https://github.com/npm/cli/tree/0783cff9653928359a6c68c8fdf30b9fd02130c9/workspaces/libnpmexec), which applies this lookup [algorithm](https://github.com/npm/cli/blob/0783cff9653928359a6c68c8fdf30b9fd02130c9/workspaces/libnpmexec/lib/index.js#L39-L41) for `package@version`:
- is package available in local modules (npm root → `~/project/node_modules/<package>`)?. **Importantly it will walk all the way down to `/` looking for `node_modules/<package>`**.
- is package available in global modules (npm root -g → `/Users/blakef/.nvm/versions/node/v17.9.0/lib/node_modules`)?
- is package available in npx cache (`~/.npm/_npx`)?
- is package available in your registry? Download to the npx cache `~/.npm/_npx/<hash>/`
At this point you'll have a cached copy, which then has its bin script run with the arguments you originally provided.
### How this works against React-Native users
Users can get their development environment into a **persistent** pickle with a bunch of unintended side-effects of npx / npm exec’s caching model:
- **It matters where you run `npx react-native`**, since it’ll default to the version of react-native in a node package's folder. This works well for us in a React Native project, but not when initializing a project outside of a package folder.
- **Global and relative node_modules really matter**. If your users runs npx react-native init and they have a version of react-native installed globally, it’ll use that version.
- If the user has a `node_modules/react-native` installation anywhere in the directory hierarchy it’ll be used. For example if I run `npx react-native init Foobar` in `/home/blakef/src/example` , npx will look for versions of react-native like this before searching globals or the npx cache:
- /home/blakef/src/example/node_modules
- /home/blakef/src/node_modules
- /home/blakef/node_modules
- /home/node_modules
- /node_modules
**nvm just makes things harder** if your user switches between versions of node it can be hard to determine if they're affected by a globally installed version. Examples include having a `.nvmrc` file in the directory they run the command which transparently switches node version (and globals location).
## Changelog:
[General][Added] - Log a warning if npx react-native uses old cached version
Pull Request resolved: https://github.com/facebook/react-native/pull/37510
Test Plan: Ran this directly from the project, defining the `npm_lifecycle_event=npx` to mock directly running using `npx`.
Reviewed By: Andjeliko
Differential Revision: D46069419
Pulled By: blakef
fbshipit-source-id: 1c1af7f639c5312760a39a0828b89b7ddf2b5fda
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37494
I'm adding some unit tests to this function that got recently added to support TvOS
Changelog:
[Internal] [Changed] - Add tests for getDependencySubstitutions
Reviewed By: cipolleschi
Differential Revision: D46029402
fbshipit-source-id: 6099242fe9e18f1a612124bc784f90047b4ee286
Summary:
I'm making sure we don't stale issues where the repro has been provided.
I'm also moving the bot to run every 10 minutes at 5AM so it will do a pass once overnight, rathern than running 4x during the day.
## Changelog:
[INTERNAL] - Do not stale issues with "Issue: Author Provided Repro"
Pull Request resolved: https://github.com/facebook/react-native/pull/37469
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D45953855
Pulled By: cortinico
fbshipit-source-id: 299aef0844ce1bc872e3156419adeff675ae2a68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37477
When creating a stack of several codegen fixes, a conflit generated some duplicated code we moved to the parsers from the utils.
This change removes that duplicated cone.
## Changelog:
[Genearal][Fixed] - Remove duplicated code.
Reviewed By: cortinico
Differential Revision: D45979013
fbshipit-source-id: 78cb89df81305221258e283ba5924135d498e800
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37475
We recently landed a change with a typo in the interface declaration. We just fixed the typo
## Changelog:
[General][Fixed] - Fixed a typo in the interface declaration
Reviewed By: robhogan
Differential Revision: D45978419
fbshipit-source-id: f44dbcd5c1706b9582b997a5eb6c0a82d0e422cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37481
ViewManagers inherit from BaseJavaModule so we should honour the same lifecycle for them as we do for native modules, which is to call `invalidate` / `onCatalystInstanceDestroy` when the ReactContext is destroyed. This allows the ViewManager to do any cleanup which cannot happen at the View level.
Changelog: [Android][Fixed] ViewManagers now receive an invalidate callback
Reviewed By: cortinico
Differential Revision: D45945678
fbshipit-source-id: 27c26d951b50a734c42eb033a46e599ef939e29f
Summary:
X-link: https://github.com/facebook/metro/pull/987
While working on https://github.com/facebook/react-native/pull/35786 I noticed some inconsistencies in the versioning for Babel and Flow across the monorepo. So in this PR I wanted to address that so that for 0.72 we'll have the codebase in a more consistent shape.
Happy to split in multiple PRs if needed.
## Changelog
[GENERAL] [CHANGED] - Bump Babel packages to ^7.20.0 (or closest latest release), bump flow parser to 0.206.0 in a few places that were left out from latest bump
Pull Request resolved: https://github.com/facebook/react-native/pull/35787
Test Plan: CI is green.
Reviewed By: cipolleschi
Differential Revision: D42384881
Pulled By: hoxyq
fbshipit-source-id: 21fd43391d12722cf707c3cdbbb36f49c036359d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37381
SurfaceRegistry was a bridgeless-only concept, which hasn't actually diverged much from AppRegistry and doesn't support any new use-cases. It also causes additional complexity in terms of Logbox. Merge the logic with AppRegistry, and rewrite existing callers to AppRegistry.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D45730959
fbshipit-source-id: e2e2626c4dec8423aa097eff76cfa4d199f3a680
Leonardo Rota-Rossi
Luiz Ozorio
Frank Calise
shubham0142
Pranav Yadav
Siddarth Kumar
Phillip Pan
Janic Duplessis
Alex Danoff
acdlite
Luna Wei
Alex Hunt
Neil Dhar
Pieter De Baets
Nicola Corti
sophiebits
Rob Hogan
Harry Yu
Tommy Nguyen
hublot
jcdhlzq
Riccardo Cipolleschi
Oskar Eichler
Ramanpreet Nara
Mathias Stearn
Neil Dhar
Blake Friedman
Intl Scheduler
Ana Margarida Silva
Sam Zhou
Lorenzo Sciandra
