Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42267
In case anyone was to try linting the react-native repo with desktop out-of-tree platform files there, this makes things easier.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52746379
fbshipit-source-id: d59a1c1f9c84c6bee529d6bdd151a7ba680b6680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42119
Changelog: [Internal]
- Updated spec for native commands of the DebuggingOverlay to have `Array` annotation instead of a workaround with string (and serialization)
- Removed serialization in JS and deserialization on native
Reviewed By: javache
Differential Revision: D51985222
fbshipit-source-id: 3dc5a049ae4984565df9ea32fa181c5885b79539
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41842
Changelog: [Internal]
- bumps `react-devtools-*` packages to 5.0.0 across xplat
- added support for highlighting multiple host components, when hovering over component, which is represented by multiple host fibers.
See test plan, this can be reproduced with a named component, which renders multiple host components inside a React Fragment:
```
<>
<View />
<View />
<View />
</>
```
Reviewed By: gsathya
Differential Revision: D51888628
fbshipit-source-id: 2bd2d9fa50c24f478aa9406ee6bb42a47168bf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41843
Changelog:
[General] [Fixed] - inspected elements from React DevTools are now correctly highlighted on a relevant surfaces
For cases when DOM Node APIs are not available (Paper or Fabric without these APIs), we will use newly added `isChildPublicInstance` from renderer.
Similarly to D51713089, this updates implementations to highlight elements only on a single AppContainer.
Reviewed By: javache
Differential Revision: D51822874
fbshipit-source-id: d5992abed5ec6f11f04d2e1e6e6928c2a66aef7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41818
Changelog: [Internal]
Use `parentElement` API to find lowest AppContainer ancestor, which will be responsible for highlighting an inspected element or rendering trace updates frames on the screen.
Reviewed By: sammy-SC
Differential Revision: D51713089
fbshipit-source-id: d6d07481679484a518a05b58d4394999876ea7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41816
Changelog: [Internal]
Forking implementations for trace updates and element highlights from React DevTools: modern and legacy.
Both implementations will later solve the same problem of highlighting the component only on a single AppContainer, but with different approaches:
- Modern will be based on DOM Node APIs: `getBoundingClientRect` and `parentElement`.
- Legacy will be based on `isChildInstance` from renderer and `measure`.
All corresponding API call will be added in a separate diff later on top of these changes.
Reviewed By: sammy-SC
Differential Revision: D51713087
fbshipit-source-id: 1c840d711a541085b1075711f737a8dbc1e31637
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41749
Changelog: [Internal]
- Each trace update frame will have its own unique id, which will be the react tag of the corresponding host fiber.
- Based on these ids, previous frames will be rerendered, not
just removed once new frames are sent from React DevTools.
- Imagine a case when there are 2 components on the screen: the first one rerenders once in a second and the second component rerenders much more frequently, each 5 milliseconds. With our previous implementation, update frames for first component will be removed once the second component has been rerendered.
- Each frame will have a lifetime for 2 seconds, it resets if frame with the same id was sent again from JS (basically component rerendered again, while we were highlighting it).
Android demo:
https://pxl.cl/3Vllz
Reviewed By: sammy-SC
Differential Revision: D51708054
fbshipit-source-id: 7abff9c1a334dccb3a1c08a46487d4bb99cdc448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41746
Changelog: [Internal]
Now using previously added `highlightElements` and `clearElementsHighlights` commands.
[Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times.
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51708053
fbshipit-source-id: f94a1bb1f5b876a153d305eeacf65b8a5eca2a08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41745
Changelog: [Internal]
Support `highlightElements` and `clearElementsHighlights` commands in `DebuggingOverlay` native components.
These later will be used for highlighting inspected component in React DevTools. These commands unblock highlighting elements on the native side, currently we do it on JS side and it mutates the React tree.
We still need to serialize the array before passing it to the native command, because codegen doesn't support it yet.
Reviewed By: javache
Differential Revision: D51603861
fbshipit-source-id: da837b0fc32e36980f207166a679fb8124ff6100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41744
Changelog: [Internal]
With these changes:
- DebuggingRegitry is responsible for listening to the events from React DevTools and
- AppContainer renders DebuggingOverlay component and subscribes with its reference to the DebuggingRegistry
- [Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51603860
fbshipit-source-id: 92b029eb54ef63b27af970770eb522915578a0b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41743
Changelog: [Internal]
There will be a single DebuggingRegistry instance per runtime, which will be responsible for finding lowest AppContainer ancestor for highlighted component.
It will receive refs to root views (ancestors, AppContainers) as subscriptions and later will call all necessary methods.
In the next series of diffs, subscriber will also provide reference to the DebuggingOverlay, on which DebuggingRegistry can call all necessary methods to highlight elements.
Reviewed By: rshest
Differential Revision: D51536787
fbshipit-source-id: e89f9d466a7e7833733981ff0d3ce2dbe349aaaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42249
Changelog: [Internal]
Manually patching public React renderers artifacts to include `isChildPublicInstance` method, which was added in https://github.com/facebook/react/pull/27783.
To identifly the required changes in code I've ran a diff for 2 commits:
1. The one with the changes
2. Its parent
FB implementation were synced in D51816108.
Reviewed By: sammy-SC
Differential Revision: D52697885
fbshipit-source-id: c62af6e89e8da3ee6f6c7264bacf6e96030e9db8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42285
Changelog: [Internal]
Having a static import of `ReactFabric` blocks from using `ReactNativeElement` class for Paper-only applications.
Although DOM Node APIs are Fabric-only, the ability to use `instanceof ReactNativeElement` is a nice tool for gating purposes, which currently can't be used because of the static import.
Reviewed By: rubennorte
Differential Revision: D52784886
fbshipit-source-id: 705c6ce0b5912d9857d730ebf1e1ecf629e2b8af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42247
With this change I make `ReactNativeConfig` a JNI class loaded at Fabric Loading time.
This removes the default from `EmptyReactNativeConfig.java` and makes sure we do read the defaults from C++ `ReactNativeConfig.cpp` file.
Changelog:
[Internal] [Changed] - Make ReactNativeConfig a JNI Class
Reviewed By: motiz88
Differential Revision: D52696653
fbshipit-source-id: 99d5e37c65e0e59efcee2c857bb94194fb40d87d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42287
Changelog: [Internal]
`run-ci-e2e-tests.js` currently skips past package build errors and tries to keep going. At best, this fails somewhere downstream of a build error (without any clear diagnostics as to why). At worst, this can miss errors entirely.
Here we extend the script's existing error handling behaviour to cover errors during the build script. It's probably worth following up to make sure all unexpected failures bubble up and stop the script, as opposed to the current error-swallowing default.
Reviewed By: hoxyq
Differential Revision: D52785131
fbshipit-source-id: 08deedfdf5b3d3cb63e77c74b47eb75570a58fbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42248
I'm duplicating the AndroidManifest.xml file internally/externally as Gradle is really unhappy with it (and gets really noisy):
- It contains a package declaration which should be removed
- It contains a uses-sdk which should also be removed
Changelog:
[Internal] [Changed] - Fix AndroidManifest.xml for RN-Tester in OSS
Reviewed By: christophpurrer
Differential Revision: D52694108
fbshipit-source-id: bb88e6f58cc8cf3a624be4b58bb409535a283a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42265
Adds a snapshot test against the `react-native` package which emits the shape of all Flow-typed modules under `Libraries/`, as an approximation of the public JS API.
This provides:
- Visibility for maintainers on any PR which changes the shape of the public API.
- An at-a-glance diff of changed APIs between React Native versions (useful for library integrators and the Release Crew).
Note — **workflow change**: Maintainers modifying public files/function signatures under Libraries/ will need to run `yarn jest -u` and commit the updated snapshot changes.
Changelog: [Internal]
Reviewed By: TheSavior, philIip, mdvacca
Differential Revision: D52729777
fbshipit-source-id: 90ca2924b50205485b6d49e52a2889d8e00a43b9
Summary:
X-link: https://github.com/facebook/yoga/pull/1547
Pull Request resolved: https://github.com/facebook/react-native/pull/42251
Yoga has an odd behavior, where `start`/`end` edges under row-reverse are relative to flex-direction, instead of writing direction.
While Yoga doesn't actually document what this behavior is supposed to be, it goes against CK documentation, historic RN documentation, and the behavior valid on the web. It is also applied inconsistently (e.g. sometimes only on container, sometimes on child). It really is a bug, instead of an intended behavior.
We changed the default behavior for Yoga, but left the existing one behind an errata (so existing fbsource users got old behavior). We have previously seen this behavior show up in product code, including CK when running on FlexLayout.
`row-reverse` is surprisingly uncommon though:
1. Litho has <40 usages
2. RN has ~40 usages in `RKJSModules`,~30 in `arvr/js`, ~6 in `xplat/archon`
3. CK has ~80 usages
4. NT has ~40 usages
There are few enough, mostly simple components, that we can inspect through each of them, looking for signs they will hit the issue (at the potential chance of missing some).
CK accounts for 10/14 usages that I could tell would trigger the issue, since it only exposes start/end edge, and not left/right. It might make sense to make it preserve behavior instead, to reduce risk a bit.
FlexLayout is now separately powering Bloks, which wasn't surveyed, so I didn't touch CK behavior under Bloks.
There could also be other usages in other frameworks/bespoke usages, and this has implications for OSS users. But based on our own usage, of many, many components, this seems rare.
Changelog:
[General][Breaking] - Make `start/end` in styles always refer to writing direction
Reviewed By: pentiumao, joevilches
Differential Revision: D52698130
fbshipit-source-id: 2a9ac47e177469f30dc988d916b6c0ad95d53461
Summary:
Original commit changeset: 9305bc56ba6b
Original Phabricator Diff: D52642168
bypass-github-export-checks
changelog: [Android][Fix] Backout fix that prevented scroll event in nested scroll when scrollEnabled = false, due to causing bugs when interacting with keyboard events
Reviewed By: bvanderhoof, arushikesarwani94
Differential Revision: D52736596
fbshipit-source-id: fa8c5c598e049cc58410892813825852c431eee4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41978
I'm revering the removal of ReactModule codegen.
We are postpoinging the removal of the codegen for the future, the reasons are:
- resources: the experiment that removes the codegen shows neutral metrics, but the codegen is shared between bridge and bridgeless, so we will need to implement and test the removal for bridge and we don't have the time to do this right now.
- reduce fragmentation: we don't want to fragment NativeModules configuration between bridge and bridgeless, doing so will bring a lot of confusion to developers
- we don't want to introduce a public APIs in 0.73 that we know they are not used in production for now, we better remove these "unstable" apis before 0.74 cut
Note: I'm updating ReactAndroid.api because this is an intended change of APIs which were not part of 0.73 and we don't want them to be part of 0.74.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D52223650
fbshipit-source-id: 681bf5e4aab776505f64b1972a6ace6340db4587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42259
At the end of last year, we reduce build fragmentation in iOS making sure that we were always building both architecture.
In the process, we break the semantic od RCt_NEW_ARCH_ENABLED flag, making several libs stop working in one of the two archs.
This change should restore the semantic, so libraries that were using RCT_NEW_ARCH_ENABLED to run conditional code will still work in the same way. While doing so, I also removed the new USE_NEW_ARCH as we don't want unnecessary flags
## CHANGELOG:
[iOS][Fixed] - Bring the old RCT_NEW_ARCH_ENABLED semantic back for compatibility
Reviewed By: cortinico
Differential Revision: D52727792
fbshipit-source-id: e211b10e7885eada83dd2886375575133ca76c8c
Summary:
Yesterday we landed a change that removed tests for the Old Architecture for RNTester.
That was the right call as there are no build differences in RNTester between the two architectures. But we do have runtime differences, and we had an integration test running on RNTester that we deleted with the previous PR.
This change restores that test, adding this only new job to run that test
## Changelog:
[Internal] - Add back an old arch integration test
Pull Request resolved: https://github.com/facebook/react-native/pull/42262
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D52730661
Pulled By: cipolleschi
fbshipit-source-id: 10fbc2540abeebc72f635451f6f650827cf20041
Summary:
This PR fixes issue in `RNTester` causing labels and image background to not be visible in dark mode in `SnapshotExample`
It also fixes issue with description in `Header` not being visible in other components examples when using dark mode
Before & After
<img width="505" alt="image" src="https://github.com/facebook/react-native/assets/56474758/ce87df69-4b79-48a0-b9be-4a7335329b78">
## Changelog:
[INTERNAL] [FIXED] - Fix dark mode in SnapshotExample in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41222
Test Plan:
1. Launch `RNTester` with dark mode enabled
2. Open `Snapshot / Screenshot` example
3. All labels should be visible, image background should have white color
Reviewed By: cortinico
Differential Revision: D52685754
Pulled By: NickGerleman
fbshipit-source-id: 72f79be45d9c65e307553832592563461a64ff1d
Summary:
As discussed with cipolleschi, RNTester shouldn't be tested for Old Arch. This PR removes those unnecessary pipeline runs
## Changelog:
[INTERNAL] [REMOVED] - remove old architecture pipeline for RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/42245
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D52694176
Pulled By: cipolleschi
fbshipit-source-id: a607bac4659b0611d5f49b5e45134f896bb96a91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42230
While developing Xcode 15, Apple reimplemented the linker.
In Xcode 15.0, the linker was making old iOS (< 15) crash when they were built using Xcode 15.
To fix that, we make Apple create new compiler flags (`-ld_classic`) to have a backward compatible linker.
In Xcode 15.1, Apple fixed that behavior, so the flags should not be required anymore.
But now, if we pass `-ld_classic` to the linker and we have an app that is using `use_framworks!`, that app crashes at startup.
This change remove the flags if the Xcode that is used is 15.1 or greater.
*Note:* The previous change added the flags to Hermes as well. I tested this fix in a configuration where Hermes has the flags and React Native does not, and it works. So we are removing the flags only from React Native.
This Fixes https://github.com/facebook/react-native/issues/39945
## Changelog:
[Internal] - Do not add the `-ld_classic` flag if the app is built with Xcode 15.1 or greater.
Reviewed By: cortinico
Differential Revision: D52658197
fbshipit-source-id: 37d6bc895921c0fc3661f301870477191e7e42b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42185
We've rolled out some changes to the behavior here, mainly that throttling no longer happens by default on iOS.
This updates the documentation, in concert with https://github.com/facebook/react-native-website/pull/3971
Changelog:
[General][Changed] - Update API docs for scrollEventThrottle
Reviewed By: javache
Differential Revision: D52516092
fbshipit-source-id: 7be1d6e1bc62f38c795b64ad4be5d5c1b23bb742
Summary:
## Stack
These can suss out some real bugs, and helps further avoid mismatch with downstream MSVC on /W4 as used by MSFT.
I enabled the families of warnings, but suppressed some major individual warnings that weren't clean. But I did clean some up, notably, missing initializer, and shortening 64 bit to 32 bit. We can do some of the rest incrementally (e.g. `-Wunused-parameter` has a fixit).
This change illuminates that MapBuffer is missing 64 bit integer support, but we often pass 64 bit counters to it, which is a bug. For now I just left TODOs around those.
`rn_xplat_cxx_library` is used for external libraries interfacing with RN, which we probably don't want to police, so I structured these stricter warnings as an opt-in flag, only enabled for our own rules.
## Diff
This fixes up source code to avoid emitting the extra warnings now enforced. Of what is enabled, this is mostly shortening 64 to 32, or missing field in initializer.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D52589303
fbshipit-source-id: 11cb778d065799fd0ead3ae706934146d13500bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42214
These methods are only used in the legacy React renderer. The Fabric renderer calls into different methods. So, let's just leave these unimplemented.
NOTE: I introduced the warning back into clearJSResponder, because I couldn't find the internal call-site to it.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52449787
fbshipit-source-id: bd001c0ca4a3e64aaaf6328b3322025b09ee6da9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42218
## Changes
This diff makes the native view config interop layer on Android lazy.
As in: ViewManagers that were registered lazily with React Native will no longer be eagerly initialized by the nvc interop layer.
Changes to UIManager apis:
- UIManager.getConstants() now **only** contains the view configs for the eager view managers.
- UIManager.getConstantsForViewManager(name): lazily load view configs for lazy components
- UIManager.getDefaultEventTypes(): load default event types
- UIManager.getConstants().LazyViewManagersEnabled: true, if there are lazy view managers
- UIManager.getConstants().ViewManagerNames: a list of the lazy view managers
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D52399280
fbshipit-source-id: d9cd46de0507ecfe6cca5595a237e1063f60fa62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42213
This improves resiliency of the native view config interop layer.
In open source, some packages might provide ViewManagers eagerly, while others might them lazily.
This also fixes another problem: Prior, eager view managers would be created **then destroyed *wastefully*** by the native view config interop layer.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399003
fbshipit-source-id: 3345c82789f1ed8e613139a8323dac4b4a01d173
Summary:
This diff should not change any behaviour.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399000
fbshipit-source-id: 976f5740c53d58ceead7d2bc4c9e0eb3f97ebb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42215
This diff should not change any behaviour.
**Why:** This logic is only used once from the UIConstantsProviderManager. So, let's just inline it. Inlining this method will make ReactInstance.java have fewer private methods, which'll make ReactInstance.java easier to read.
**Concern:** Inlining this method into ReactInstance's constructor will make the constructor too hard to read.
- I think it'll be fine: we will simplify this method significantly in D52399003.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399002
fbshipit-source-id: 8c0dc69af86109da8144546347eecd2e01c0e0be
Summary:
When a FlatList is in side a scroll view (think Netflix style navigation), the DPAD up/down fires on the scroll view, despite scrollEnabled={false} being set. This additiontially conflicts with any custom scroll event that has been created.
## Changelog:
[Android] [Fixed] - fix: prevent scroll event in nested scroll when scrollEnabled={false}
Pull Request resolved: https://github.com/facebook/react-native/pull/42219
Test Plan:
I tested this by making a ScrollView with FlatList of opposite scrolling direction inside with basic card layouts.
Both had scrollEnabled={false}
I scrolled the ScrollView myself as it has multiple rows using:
```
const scrollToItem = React.useCallback(
(itemIndex: number): void => {
const targetScrollY = itemIndex * height
scrollViewRef.current?.scrollTo({ y: targetScrollY, animated: true })
},
[height]
)
React.useEffect(() => {
// Row 0, is global nav, but it's also the first row of cards
// when we scroll to "1" what we mean is global nav is hidden
// we should still be showing the first row of items.
scrollToItem(rowIndex <= 1 ? 0 : rowIndex - 1)
}, [rowIndex, scrollToItem])
```
Reviewed By: NickGerleman
Differential Revision: D52642168
Pulled By: mdvacca
fbshipit-source-id: 9305bc56ba6b03b04b9f69a14d433593cab2025e
Summary:
`compose-source-maps.js` fails if `-o` is not specified when it should output the composed source map.
## Changelog:
[GENERAL] [FIXED] - Fix `compose-source-maps.js` failing if `-o` is not specified when it should output the composed source map
Pull Request resolved: https://github.com/facebook/react-native/pull/42203
Test Plan:
Tested this in an internal repo. This was the output before this fix:
```
% node node_modules/react-native/scripts/compose-source-maps.js dist/main.jsbundle.map dist/main.jsbundle.hbc.map
node:internal/streams/writable:472
throw new ERR_INVALID_ARG_TYPE(
^
TypeError [ERR_INVALID_ARG_TYPE]: The "chunk" argument must be of type string or an instance of Buffer or Uint8Array. Received undefined
at _write (node:internal/streams/writable:472:13)
at Writable.write (node:internal/streams/writable:494:10)
at Object.<anonymous> (/~/node_modules/.store/react-native-virtual-c8e66dddc1/node_modules/react-native/scripts/compose-source-maps.js:64:20)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
at node:internal/main/run_main_module:28:49 {
code: 'ERR_INVALID_ARG_TYPE'
}
Node.js v20.10.0
```
Reviewed By: christophpurrer
Differential Revision: D52650438
Pulled By: arushikesarwani94
fbshipit-source-id: b8f8f01fb6d843887d874a7283a1a6807c7762e7
generatedunixname89002005325672
Neil Dhar
Eric Rozell
Ruslan Lesiutin
Nicola Corti
Moti Zilberman
Alex Hunt
Nick Gerleman
David Vacca
Riccardo Cipolleschi
Riccardo Cipolleschi
Pieter De Baets
Alex Taylor (alta)
Kacper Rozniata
Oskar Kwaśniewski
Ramanpreet Nara
Ryan Wilson
Tommy Nguyen