Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Defines module for `React-jsinspector` that for swift modules to integrate with.
to fix https://github.com/expo/expo/issues/28209, any podspec depends on HermesExecutorFactory should use ` add_dependency(s, "React-jsinspector", :framework_name => 'jsinspector_modern')` to add dependency. otherwise it will encounter the header not found issue because use_frameworks will change "jsinspector-modern" to "jsinspector_modern".
to depend on React-jsinspector from expo-modules-core, we need it to define as a module.
otherwise, it will have the error
```
The Swift pod `ExpoModulesCore` depends upon `React-jsinspector`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
## Changelog:
[IOS] [CHANGED] - Add `DEFINES_MODULE` for React-jsinspector.podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/44252
Test Plan: ci passed
Reviewed By: cortinico
Differential Revision: D56575102
Pulled By: cipolleschi
fbshipit-source-id: 9b7b4568a3e499f0a741a79a846263118ff2d112
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44231
changelog: [internal]
The flag is not used and is statically set to false, let's delete it.
Reviewed By: NickGerleman
Differential Revision: D56473851
fbshipit-source-id: fe1076d20a765ffed2437f080764f2b5fe060bb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44232
changelog: [internal]
surfaceId parameter is not needed `schedulerDidRequestPreliminaryViewAllocation` as it can be derived from shadow node.
Additionally, conversion to ShadowView can happen on the lower layers.
Reviewed By: NickGerleman
Differential Revision: D56350599
fbshipit-source-id: 9c38cc0df36911bbd6927fe0a0d5e64c248d87c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44167
We received an issue for OSS where, when the main window is inactive and the system tries to present a dialog, the dialog is not presented in the right position on the screen.
This change introduce a fallback to the first inactive window (which is still visible on screen) and it fixes the issues.
## Changelog:
[iOS][Changed] - Fallback to the first `foregroundInactive` window when there are no `foregroundActive` windows in RCTKeyWindow
Reviewed By: dmytrorykun
Differential Revision: D56354741
fbshipit-source-id: fa23131ecd40f6d91c705879a72890506ee21486
Summary:
Inside [Re.Pack](https://github.com/callstack/repack) we consume command's options, to reduce the amount of assumptions that 3rd party tools need to make - we can move assigning default value to config command level, so default values will be aligned across tools.
For default `start` command this change doesn't change any behaviour.
## Changelog:
[INTERNAL] [CHANGED] - Add `localhost` as default host in `start` command config
Pull Request resolved: https://github.com/facebook/react-native/pull/44244
Test Plan: `start` command should work the same way as before.
Reviewed By: huntie
Differential Revision: D56567793
Pulled By: blakef
fbshipit-source-id: fe8f3686ae39a3d2996de11930a0d03364692adc
Summary:
Web props work (somewhere around D41230978 and D39268920) made it so that numeric font weights can be set instead of just strings. This is implemented by converting number to string before passing to native component within the `Text` component.
We have crash with:
```
2024-04-19 09:38:21.360 16963 17190 E ViewManager: Error while updating prop fontWeight
2024-04-19 09:38:21.360 16963 17190 E ViewManager: java.lang.IllegalArgumentException: method com.facebook.react.views.text.ReactBaseTextShadowNode.setFontWeight argument 1 has type java.lang.String, got java.lang.Double
2024-04-19 09:38:21.360 16963 17190 E ViewManager: at java.lang.reflect.Method.invoke(Native Method)
```
`TextStyleProps` can also be passed to `TextInput`, which passes to underlying native component, without going through this logic. And the types for Native props directly derive from JS props, so type system does not catch passing incorrect number type to underlying native component.
This does a quick and dirty replication of the exact logic in `Text.js` to `TextInput.js`. I'd love to potentially fix this up for Fabric in a different way when we rethink CSS parsing.
Changelog:
[General][Fixed] - Handle `fontWeight` normalization for TextInput component
Reviewed By: arushikesarwani94
Differential Revision: D56539571
fbshipit-source-id: 8975886c117d814a624f817bffe408841bb03b88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44236
## Changelog:
[Android] [Fixed] - fix a case when view preallocation or props forwarding on Android lead to dropped props update
# What does this fix
This fixes a bug where prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`.
This affects android only and when batched rendering is enabled.
There are two root causes of this problem:
1. View preallocation on Android: https://fburl.com/code/r62p3vot
2. Prop forwarding on Android: https://fburl.com/code/644f1ppk
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is combination of view preallocation and batched rendering updates.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
# The fix
The fix is to change two things:
1. Ignore view preallocation for shadow nodes which were cloned with new props.
2. Set hasBeenMounted flag on ShadowNode later in the Fabric pipeline to fix it.
Both of these are hidden behind a single feature flag: `fixMountedFlagAndFixPreallocationClone`
## Performance implication:
I estimate that this will impact around 3% of views.
Reviewed By: rubennorte
Differential Revision: D56353589
fbshipit-source-id: 651d3cd2d0f78bfbbe9c05aa1ae1b1690c15e4ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44188
The current approach used for `batchRenderingUpdatesInEventLoop` is not compatible with Android due to limitations in its props processing model. The raw props changeset is passed through to Android, and must be available for the Android mounting layer to correctly apply changes.
We have some logic to merge these payloads when multiple ShadowNode clones take place but were previously assuming that a ShadowTree commit was a safe state to synchronize.
In the current implementation this means that two commits driven from layout effects (triggering states A → B → C) may cause Android to observe only the B → C props change, and miss out on any props changed in A → B.
Changelog: [Android][Fixed] Cascading renders were not mounting correctly when `batchRenderingUpdatesInEventLoop` is enabled.
Reviewed By: rubennorte
Differential Revision: D56414689
fbshipit-source-id: 7c74d81620db0f8b7bd67e640168afc795c7a1d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44233
The package was added to our build scripts, but shouldn't have been. We're not exporting this package or making it public.
Changelog: [Internal]
This should unblock our OSS CI.
Reviewed By: cipolleschi
Differential Revision: D56513694
fbshipit-source-id: f37c75871253b2570fb933175165d8f0a9593a16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44197
Changelog: [General][Breaking] Remove executeAsynchronously and executeSynchronously_CAN_DEADLOCK
these are not used anywhere nor in OSS, we can delete this safely
Reviewed By: javache
Differential Revision: D56447959
fbshipit-source-id: d66c10f676946422385750c1b8825ead2d5d0ed8
Summary:
This is a copy of the current packages/react-native/template that we exclusively use internally for testing.
Changelog: [Internal]
NOTE: Best contribution would be to scan the file list and ensure there isn't anything that shouldn't be in there.
bypass-github-export-checks
Reviewed By: cortinico, cipolleschi
Differential Revision: D56242484
fbshipit-source-id: 0913ff7acff9b0314b49f48e986674b77dbb908e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44209
## Changelog:
[Android] [Fixed] - When React Native is destroyed, unmount all Fabric surfaces.
Previously, Fabric surfaces would not be torn down. Meaning that passive and layout effects wouldn't be unmounted and surface infra wouldn't be cleaned up.
For example:
```
useEffect(() => {
return () => {
console.log('unmounted');
}
)};
```
When calling `ReactNativeHost.clear()` on Android in native code, the above effect should be unmounted.
This is a requirement for Fabric.
Reviewed By: javache
Differential Revision: D56238947
fbshipit-source-id: 5dbf5cdef520f34c78953c2b8f2d42349549e893
Summary:
This decouples the listing of modules from the linking of those modules into Cocoapods. I've made this backwards compatible, but our internal template wont lean on the community config.
The user can now override how they capture a list of React Native modules, providing an escape hatch for Framework authors to build on.
Changelog: [General][iOS] Use our fork of the react-native-communti/cli-platform-ios use_native_modues.rb script
Reviewed By: cipolleschi
Differential Revision: D56242486
fbshipit-source-id: 78505669ab6abd6718348388c3bfba3290f7071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44206
Changelog: [internal]
We finally managed to implement mount hooks without reliability issues on Android, so we can clean up the feature flag and enable it unconditionally.
Reviewed By: cortinico
Differential Revision: D56467379
fbshipit-source-id: d797ec770b731135332bc9f39df1c1e684b3bde4
Summary:
This change is a preliminary change to add support to `Long` and `long` React props that are required for supporting WideGamut color space.
## Changelog
[Android][Added] - Extend Property Processor to support long props
Reviewed By: cortinico
Differential Revision: D56461183
fbshipit-source-id: 0f70388abe2b414a09df640f04e767f1164d63ce
Summary:
This adds support for enabling wide color gamut mode for ReactActivity per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738).
## Changelog:
[ANDROID] [ADDED] - Add isWideColorGamutEnabled to ReactActivityDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/43036
Test Plan:
Update RNTesterActivity.kt to enable wide color gamut:
```diff
class RNTesterActivity : ReactActivity() {
class RNTesterActivityDelegate(val activity: ReactActivity, mainComponentName: String) :
// ...
override fun getLaunchOptions() =
if (this::initialProps.isInitialized) initialProps else Bundle()
+ override fun isWideColorGamutEnabled() = true
}
```
Reviewed By: cortinico
Differential Revision: D55749124
Pulled By: cipolleschi
fbshipit-source-id: 44dd5631e1a2e429c86c01ed8747bbebbc8bdb3b
Summary:
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.
bypass-github-export-checks
## 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.
Reviewed By: cortinico
Differential Revision: D55749058
Pulled By: cipolleschi
fbshipit-source-id: 37659d22c1db4b1a27a9a4f88c9beb703517b01f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44182
## Changelog:
[iOS] [Fixed] - Fixed stale state on TouchableOpacity and TouchableBounce
When TouchableOpacity and TouchableBounce are unmounted, we need to reset their state. This includes animation state. If we don't do that, view is unmounted on the mounting layer and animation will not be applied. This leaves view in undefined state. In TouchableOpacity, it is view with reduced opacity. TouchableBounce that is view with applied transform.
This was reported in https://github.com/facebook/react-native/issues/44044
Reviewed By: rubennorte, cipolleschi
Differential Revision: D56416571
fbshipit-source-id: 01214ec8a5e07c80a609e082b955a30305ad8396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44196
Changelog: [Internal]
BufferedRuntimeExecutor is unnecessarily coupled with these other targets (React-runtime, React-cxxreact), break that dependency so we can modularize this file
Reviewed By: realsoelynn
Differential Revision: D56382644
fbshipit-source-id: ed9725fbddcda04b73c583d927351440b4fc3328
Summary:
After creating a new project with `npx react-native init`, line 39 in `project.pbxproj` contains both spaces and tabs for indentation (accidentally introduced in 520d120375). This line will be unnecessarily touched and rewritten by a subsequent `pod install`.
Fix the indentation by replacing 4 spaces with one tab character (the Xcode managed file exclusively uses tabs for indentation).
## Changelog:
[GENERAL] [FIXED] - Fix space/tab indentation in template project.pbxproj
Pull Request resolved: https://github.com/facebook/react-native/pull/44186
Test Plan: Generate project again with change and observe that the file will be generated with the expected indentation.
Reviewed By: NickGerleman
Differential Revision: D56439289
Pulled By: arushikesarwani94
fbshipit-source-id: ced9f0c94757a4925cd01673c65f2c38d28629e6
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there was a callsite to fstat in our forked copy of glog, so use C617.1.
callsites:
- glog/src/logging.cc
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625116
fbshipit-source-id: b10ea2dad2238cc85b5fe30df56269a5808a35b5
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there were callsites to fstat variants in our forked copy of boost, so use C617.1.
callsites:
- RCT-Folly/folly/FileUtil.h
- RCT-Folly/folly/portability/SysStat.h
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625114
fbshipit-source-id: fb388f474e62543828218925b0d409d4b558c3db
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there were callsites to mach_absolute_time and fstat variants in our forked copy of boost, so use 35F9.1 and C617.1 respectively.
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625113
fbshipit-source-id: 0dcd216116595d1bb14e6b843f711aac68f84e5c
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (JSBigString)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55624716
fbshipit-source-id: 400e9852a64e7f9fd9e32225b199f2664a069fc2
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (RCTJavaScriptLoader)
- CA92.1 (RCTI18nUtil, RCTBundleURLProvider, RCTSettingsManager)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55622471
fbshipit-source-id: f6ab864f51d4fa6e20f5de4fd56d8126d55dea8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
codegen generates type alias for array enum props with uint32_t which cause wrong overloaded fromRawValue to call at runtime eventually app to terminate
more detailed info at issue https://github.com/facebook/react-native/issues/43821
## Changelog:
[Internal] [Fixed] - Codegen for array enum props
Pull Request resolved: https://github.com/facebook/react-native/pull/44123
Test Plan: TODO
Reviewed By: cipolleschi
Differential Revision: D56414554
Pulled By: dmytrorykun
fbshipit-source-id: 0ec1b65951bc16ff58dd2b119c97a4e3fac2b161
Summary:
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react-fbsource-import on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
diff-train-source-id: 13710c68616cf643d3cdfd69e5f39b2dc5a801b4
Generated by: https://www.internalfb.com/intern/sandcastle/job/36028798276627863/
GitHub Repo: facebook/react-fbsource-import
Reviewed By: jackpope
Differential Revision: D56357596
fbshipit-source-id: 171ed7b816869348a1cc3c06a78b3803b86eb7c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44180
Changelog: [General][Changed] Update Chrome launch flags for `--experimental-debugger` launch flow
Internally at Meta, we've been testing the experimental debugger launch flow with a different set of Chrome flags than are currently shipped in open source. This diff fixes those differences:
* Removes `--disable-backgrounding-occluded-windows`
* Adds `--guest`
Reviewed By: EdmondChuiHW
Differential Revision: D56418271
fbshipit-source-id: 884c5746e93cad89f17e4ef9e3ef193a2a454eb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44179
Fix `package.json#exports` main entry point in `react-native/oss-library-example` (which is actually at `packages/react-native-test-library`), to fix a Metro resolver warning on building RN-tester.
`"./": "./index.js"` is intended as an export map entry for the main export, whereas `".": "./index.js"` is correct (see [`PACKAGE_EXPORTS_RESOLVE`](https://nodejs.org/api/esm.html) spec).
Changelog: [Internal]
(This package is not published)
Reviewed By: cortinico, dmytrorykun
Differential Revision: D56414480
fbshipit-source-id: 01874cf11ae687aaf5aa5aa56075232f03d691b8
Summary:
This is a follow-up to https://github.com/facebook/react-native/pull/44075. I've missed the fact that `ReactConstants.UNSET` is `-1` and the default value of `numberOfLines` prop is `0`. This resulted in font size being set to the minimal value when `adjustFontSizeToFit` was used without setting `numberOfLines` to a positive value.
## Changelog:
[ANDROID] [FIXED] - Fixed `adjustFontSizeToFit` when used without `numberOfLines`
Pull Request resolved: https://github.com/facebook/react-native/pull/44165
Test Plan:
<details>
<summary>Tested on the following code</summary>
```jsx
import { Text, SafeAreaView, View, StyleSheet } from 'react-native';
export default function Test() {
return (
<SafeAreaView style={styles.container}>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some text that fits (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some text that fits (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some text that fits (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some text that fits (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some longer text that doesn't fit if displayed in one line (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some longer text that doesn't fit if displayed in one line (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, 2 lines)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, 2 lines)
</Text>
</View>
</SafeAreaView>
);
}
```
</details>
|Old arch|New arch (without this PR)|New arch (with this PR)|
|-|-|-|
|<img width="447" alt="a_old" src="https://github.com/facebook/react-native/assets/21055725/4822f7f1-a19c-4225-9318-0eb2fec6f925">|<img width="447" alt="a_new_no_change" src="https://github.com/facebook/react-native/assets/21055725/ff594673-b362-4a81-8837-624cb1061d28">|<img width="447" alt="a_new_changed" src="https://github.com/facebook/react-native/assets/21055725/1f29c01c-1c91-4c9f-9edd-0950338b5d39">|
Reviewed By: NickGerleman
Differential Revision: D56362020
Pulled By: cortinico
fbshipit-source-id: 2aecbe66043870cf14536850ecbfb7c3890acd72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42115
React Native Android had a concept called JSIModules, which iOS doesn't have. The JSIModule concept was introduced in the early stages of the Fabric project to represent modules that interact with JS through JSI and they are not NativeModules.
In the new architecture this concept is not really necessary and these interfaces were only used to initialize and destroy the Fabric renderer and TurboModule Manager in react native core. Bridgeless mode doesn’t use JSIModule anymore. Also, it has an explicit list of supported JSI module types, so is not open for extension.
In order to simplify RN concepts and reduce confusion with TurboModules, which also "use JSI", deleting everything related to JSIModule. This was already deprecated in 0.74.0.
Please use ReactInstanceEventListener to subscribe for react instance events instead of getJSIModule() and we recommend using TurboModules instead of JSIModules.
Changelog:
[General][Breaking] Delete JSIModule
Reviewed By: javache, cortinico
Differential Revision: D49597702
fbshipit-source-id: bc2bc190aafaf559336b341b50ffabf413474105
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44155
Add ReactSoftException in ReactHostImpl only when `onActivityResult`, `onNewIntent`and `onWindowFocusChange` do not have the context
Changelog:
[Android][Fixed] ReactSoftExceptions in ReactHostImpl only when Context is null
Reviewed By: cortinico
Differential Revision: D56325407
fbshipit-source-id: a9f8fd5772fc05d39e72236fb8edfe5f8a9d6a43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44169
## Changelog:
[General][Changed] Disable new event loop behavior when bridgeless (new architecture) is enabled.
# What is the problem
With event loop, specifically with `batchRenderingUpdatesInEventLoop`, prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`. Note this has to be a prop change affecting mounting layer directly, not something consumed by Yoga, e.g. background colour or border colour.
This affects android only.
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is in batched rendering updates and how props are delivered to Android mounting layer.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
At first this might appear as a problem with view preallocation. But the underlaying trouble is that on Android, we currently have no way of knowing how to combine changesets from React into single folly::dynamic.
Reviewed By: javache, cortinico
Differential Revision: D56355863
fbshipit-source-id: f8616ee48e10fc10e129bb632c5d398842220d24