Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42601
After S390064, the OnDismiss event for Modal from D52445670 was reverted.
The diff was too big and caused the SEV, so we are trying to reimplement it gradually to make sure we don't brake anything.
The most important thing for our short term goal is to make the `OnDismiss` work only for iOS (following the official docs, Android never supported it) for Fabric (Bridge and Bridgeless).
We also want to minimize the changes t the JS infrastructure, so we are trying not to alter the JS APIs.
## The Problem:
The reason why the onDismiss event does not work is because, as soon as the `visible` property is turned to `false`, the component is removed by the React tree.
When this happens, Fabric deallocate the ShadowNode and the EventEmitter. Therefore, the event is not fired.
## The Solution:
We made this work by "delaying" when the component need to be removed from the reacat Tree.
Rather then rendering or node or not based on the `visible` props, we are introducing a `State` object that keeps track when the Modal is rendered or not.
The `state.isRendering` property is set to `true` when the `visible` prop is set to `true`.
For iOS, when `visible` prop is set to `false`, instead, we wait for the Native side to actually dismiss the View and to invoke the event. When the event is fired, we manually set the `state.isRendering` property to false and the Modal can be considered dismissed.
Notice that this makes also useless to have the Modal Native's snapshot to simulate that the modal is still presented.
## Changelog:
[iOS][Fixed] - `onDismiss` now work on iOS with Fabric, in both Bridge and Bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D52959996
fbshipit-source-id: 365ca1d0234e3742df9db87007523d1a4a86079f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42859
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393475
fbshipit-source-id: 442439c03e251d018f289ba4bb45dde9e6a0ab7f
Summary:
Currently if the virtualized list content is small `onStartReached` won't be called initially when the list is mounted. This is because when the content is small `onEndReached` will be called initially preventing `onStartReached` from being called. In `_maybeCallOnEdgeReached` calling `onEndReached` and `onStartReached` are in the same conditional so they cannot both be triggered at once. To improve the consistency of `onStartReached` we should call both `onEndReached` and `onStartReached` if needed.
## Changelog:
[GENERAL] [FIXED] - Call onStartReached initially when list is small and `onEndReached` is called
Pull Request resolved: https://github.com/facebook/react-native/pull/42902
Test Plan:
I used this code to test in RN Tester (replace content of RNTesterAppShared.js)
```ts
import React, { useState, useEffect } from "react";
import { StyleSheet, FlatList, View, Text, TouchableOpacity } from "react-native";
function App() {
const [data, setData] = useState(generatePosts(4));
const [idCount, setIdCount] = useState(1);
const renderItem = ({ item }) => <Item data={item} />;
const keyExtractor = (item) => item.id.toString();
console.log("-------")
return (
<View style={{ flex: 1, marginVertical: 20 }}>
<FlatList
key={idCount}
data={data}
renderItem={renderItem}
keyExtractor={keyExtractor}
onEndReachedThreshold={0.05}
onEndReached={() => console.log("onEndReached")}
onStartReachedThreshold={0.05}
onStartReached={() => console.log("onStartReached")}
inverted
/>
<TouchableOpacity style={{height: 50, width: '100%', backgroundColor: 'purple'}} onPress={()=>{
setIdCount(state => state + 1)
setData(generatePosts(2))
}}><Text> Press</Text></TouchableOpacity>
</View>
);
}
function Item({ data }) {
return (
<View style={styles.item}>
<Text style={styles.title}>
{data.id} - {data.title}
</Text>
</View>
);
}
const styles = StyleSheet.create({
item: {
backgroundColor: "#f9c2ff",
padding: 20,
marginVertical: 8,
marginHorizontal: 16,
},
title: {
fontSize: 24,
},
});
const generatePosts = (count, start = 0) => {
return Array.from({ length: count }, (_, i) => ({
title: `Title ${start + i + 1}`,
vote: 10,
id: start + i,
}));
};
export default App;
```
Before the change only onEndReached is called, after the change both onStartReached and onEndReached is called.
Reviewed By: sammy-SC
Differential Revision: D53518434
Pulled By: cipolleschi
fbshipit-source-id: bc34e0d4758df6d5833be7290e5a66efaf252ffd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42908
Changelog: [internal]
Just a small ergonomic improvement to do `ReactNativeFeatureFlags.override` instead of `ReactNativeFeatureFlags.INSTANCE.override` in Java.
We already did this for the methods to access the feature flags in the same class.
Reviewed By: rshest
Differential Revision: D53516254
fbshipit-source-id: cdaa90b3baae4f780a42a96ebb07de78bd968019
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42917
If the app is not connected to Metro, the behavior of the refresh is different between bridgeless and bridge. This is because the `handleReloadJS` is implemented differently between the two support managers. I'm fixing it.
Changelog:
[Android] [Fixed] - Fix Reload behavior being different on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D53526369
fbshipit-source-id: 63509b5595c3738a1d6d9eb4352036c174643770
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42906
Makes way to relocate repo E2E testing + Verdaccio logic under `scripts/e2e/`. The contents of this script are minimal and are better located with `rn-tester-e2e`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53516117
fbshipit-source-id: e7e50af0383788f2219da190bf921ea93a6455eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42733
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Reviewed By: philIip
Differential Revision: D53225120
fbshipit-source-id: fa6ef7fac380e17684cc02de0b4a46504b26bb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42896
Changelog:
[General][Fixed] Fix order of Metro hotkey console messages
# Existing
Key handler is printing messages to the console _after_ it has been processed, this causes error messages to appear before the `info` message.
# In this PR
The `info` messages are logged before the event is processed.
Reviewed By: GijsWeterings
Differential Revision: D53479732
fbshipit-source-id: 25af47450662de4eb03d0dfd52af5af014ef3e49
Summary:
For Bridgeless mode we set `fabric` and `concurrentRoot` property for newly initialized views. This example overwrites those properties. I think we should Instead copy previous dictionary and only overwrite `color` key.
This issue results in a warning: "Using Fabric without concurrent root is deprecated. Please enable concurrent root for this application."
Note: This Example crashes on Bridgeless but my other PR https://github.com/facebook/react-native/issues/42263 fixes it.
## Changelog:
[INTERNAL] [FIXED] - UpdatePropertiesExampleView to mutate existing `appProperties` instead of overwriting
Pull Request resolved: https://github.com/facebook/react-native/pull/42634
Test Plan:
1. Wait for this example to get fixed for Bridgeless
2. Click the button to update props
3. Check if there is no warning
Reviewed By: cortinico
Differential Revision: D53126953
Pulled By: cipolleschi
fbshipit-source-id: fa0e8bda50a47696467d279845616c2ba51fe310
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42821
As the title says, we want `concurrentRoot iif fabric`.
This makes sure we invoke renderApplication correctly.
Changelog:
[Internal] [Changed] - Set concurrentRoot to true whenever Fabric is used in renderApplication
Reviewed By: sammy-SC
Differential Revision: D53353017
fbshipit-source-id: 8de88adf528eb71f233233bd85c2c6ef9430fb16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42892
## Changelog:
[Internal]-
This adds an ability to have multiple custom source transformers when resolving asset sources, which is beneficial in some scenarios.
The transformers are chained, being executed in order they are registered, until one of them returns a non-null value.
If none does, then the default one is returned.
Reviewed By: GijsWeterings
Differential Revision: D53472320
fbshipit-source-id: ed9baf8789b8bd41c8ce78eed71ebb65868cf178
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42829
This is the base query method that we can wrap to use specific matchers like `findByTestID` or `findByRole`
Changelog: [internal]
Reviewed By: noahlemen
Differential Revision: D53359005
fbshipit-source-id: d1ac9c503b05d479567b6ced71d4517d5bc55b0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42873
Changelog:
[iOS][Fixed] Disable the "Open Debugger" item from dev menu if packager is disconnected
# Existing
In our dev menu, the "Open Debugger" menu item is shown even if the packager isn't connected.
{F1434746954}
# In this PR
The "Open Debugger" menu item is disabled when the packager is disconnected.
{F1451344668}
# Reference
* Also on Android: D53428914
Reviewed By: robhogan
Differential Revision: D53354110
fbshipit-source-id: 6eb4e826fe9317798c704a5441b5e462edab1c4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42885
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
Following D53355413, we're now able to remove the previous `type: 'Legacy' | 'Modern'` page concept, implemented in this diff.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53358480
fbshipit-source-id: 62e53a1bd60760291ada3479121dfca9e1f6edbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42884
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
This updates the pages response in `jsinspector-modern` to send a capability flags configuration, replacing `InspectorPageType`/`"type"`.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53355413
fbshipit-source-id: 710f9eb11fcc61ab06bfc3051517dd4dd204c68a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42818
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
Implements a second granular flag, `nativeSourceCodeFetching`, and adds tests for this.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53352242
fbshipit-source-id: 94b62d84c731c903c5f99f8206d5c91bc501d030
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42817
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
- Implements capability flags in `InspectorProxy`, via an optional `"capabilities"` key returned by a device's CDP server.
- Wires up an initial flag, `nativePageReloads`, to disable the legacy "React Native Experimental (Improved Chrome Reloads)" page and emulated page reload behaviour.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53352244
fbshipit-source-id: 622fc6028174919b9bf776e3ac52724d97ca2734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42758
Changelog: [iOS][Added] - introduce native api to access RuntimeExecutor
The goal of this API is to provide a safe way to access the `jsi::runtime` in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners.
However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule.
This diff introduces the API that would allow for 1). The integration consists of these parts:
- wrapper object for RuntimeExecutor access, `RCTRuntimeExecutor`. The NSObject wrapper is necessary so we can make it the property of a swift module
- new protocol API,`RCTRuntimeExecutionModule`, for modules to access the RuntimeExecutor block
- integration within the bridgeless infrastructure
Reviewed By: javache
Differential Revision: D53256188
fbshipit-source-id: 8fadbe8f760cdb8928bbf3f7e4829e27b7617b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42860
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393473
fbshipit-source-id: 93e6be94cee4f852c85464ce151670b1c8f1f913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42857
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D53393472
fbshipit-source-id: 717507391623d67d03d83bf344475a4a830504a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42861
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D53393474
fbshipit-source-id: 4bbdf72729d3a84ad90a3071d8abcedefbe89878
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42856
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393476
fbshipit-source-id: b2278befdbfa45209acf36c8c73b276bb897ac8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42853
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393135
fbshipit-source-id: 74a7f710eb7bf5a2e2b39e07ee4b026a425f521c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42855
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393136
fbshipit-source-id: 29884933200a5f9251954fc3488828767a4013fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42854
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393141
fbshipit-source-id: a83840a904ba06f4dfbded2480c19d1457566f4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42852
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393137
fbshipit-source-id: 9ed2d2b28d3ad6ecb644eeb494ac2511e3b2397e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42848
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393140
fbshipit-source-id: 90e64c746a1d72cfd91876082bdc9642c72fd896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42825
This makes overrides for feature flags more predictable by only allowing a single point of overrides per app.
The previous behavior was:
* Common flags: the last override would win.
* JS flags: overrides would be combined and the last definition for each flag would win.
The new behavior, both for common flags and for JS flags, is to only have a single override.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D53360609
fbshipit-source-id: 7e299d74fada188beb1bf17eb7e25ff97015781e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42820
The feature flag system generates a significant amount of files. This reduces that number to remove noise from diffs/PRs by eliminating a file that could be defined privately within another one.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53352391
fbshipit-source-id: 51fccb3c1bb09ef3503cd34334d28c1021bd1b25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42815
Feature flags were originally defined in a JSON file for easier interoperability but we're only using the definitions in JS anyway, so having the definitions in a JS file is more flexible (e.g.: adding comments).
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53351483
fbshipit-source-id: 23fe0a3898b4facf2f2cf9645f78c45d78937f31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42871
Minor improvements:
* Removed unused imports
* No longer need to use `static const *` because now we don't rely on pointer equality (we specify the index of the array where to write now).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53416934
fbshipit-source-id: 9ea12b8398688666e6b76768d3f8fb4e1aad5d1c
Summary:
`react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos because the package may not be hoisted to the same location. For example, if `react-native/community-cli-plugin` was hoisted:
```
/~/node_modules/react-native/community-cli-plugin/dist/utils
```
It may never find `react-native-macos` if it wasn't hoisted:
```
/~/packages/my-app/node_modules/react-native-macos
```
## Changelog:
[GENERAL] [FIXED] - Fix `react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos
Pull Request resolved: https://github.com/facebook/react-native/pull/42875
Test Plan: Tested in an internal project.
Reviewed By: cipolleschi
Differential Revision: D53426607
Pulled By: robhogan
fbshipit-source-id: 29b9fe92d5773d0160bba375d2e92ec688652e3e
Summary:
Original commit changeset: 32898e1ba30b
Original Phabricator Diff: D52998256
[General][Removed] - Back out: Gradle plugin for resolving node_modules packages.
Backing this (my own diff) out as it breaks CI - I'm not sure why it landed.
Reviewed By: cipolleschi
Differential Revision: D53427912
fbshipit-source-id: baec254a463e3f7827d6a8675499aab34069ddd1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42823
This is a tiny new Gradle plugin intended to be published to the Gradle Plugin Portal independently of React Native. It's only function is to resolve `node_modules` package roots using a sufficient subset of the Node JS resolution algorithm - e.g, we can use it to find `react-native` itself from a user's project, whatever package manager or workspace setup they're using, in a Gradle-friendly, cacheable manner.
The plugin is both a `Settings` plugin and a `Project` plugin, so that it may be used from both `settings.gradle` (where we need it to resolve `react-native`) and `app/build.gradle` (which currently applies from `cli-platform-android`).
The setup is mostly `gradle init` with a few modifications (eg, Kotlin JVM version) to stay close to the setup for `react-native-gradle-plugin`. I think it's easier to reason about this currently as an entirely separate Gradle project, but we may be able to merge the two and reduce some duplication once it's proven.
Changelog:
[General][Added] - Gradle plugin for resolving node_modules packages.
Reviewed By: cortinico
Differential Revision: D52998256
fbshipit-source-id: 32898e1ba30bccabca11b623f03959a51898afe8
Riccardo Cipolleschi
David Vacca
Janic Duplessis
Alex Taylor (alta)
Rubén Norte
Nicola Corti
Alex Hunt
Edmond Chui
Oskar Kwaśniewski
Jakub Piasecki
Tommy Nguyen
Fabrizio Cucci
Ruslan Shestopalyuk
Jack Pope
Phillip Pan
George Zahariev
Rob Hogan
Samuel Susla
