Summary:
[Codegen 102] This PR is subtask of umbrella https://github.com/facebook/react-native/issues/34872. It extracts the code to compute the `extendsProps` and the props properties in Flow in a `getProps() -> {extendsProps, props}` function into the same `index.js` file. This will help unifying the `buildComponentSchema` functions between Flow and TS so we can factor it out in a later step.
## Changelog:
[INTERNAL][CHANGED] - merge `getExtendsProps` & `getProps` fns into `getProps` fn - Flow.
Pull Request resolved: https://github.com/facebook/react-native/pull/36891
Test Plan: - `yarn flow && yarn test react-native-codegen` --> *should be green.*
Reviewed By: rshest
Differential Revision: D45044653
Pulled By: cipolleschi
fbshipit-source-id: 9fcdaef60dfbc3332d880b19c6e575d948d21986
Summary:
Throws and captures the overloading class as well as the component name to help us track.
[Android][Changed] - Added an exception, which will be removed shortly.
Reviewed By: cortinico
Differential Revision: D45185598
fbshipit-source-id: 222a38be12c0a41774c83b657a4e4134ce9c197f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37004
Currently in RN Android when re-creating the context we don't unmount the underlying React application. This violates ViewManager and React hooks contracts, who are no longer able to properly unmount views, and instead the view hierarchy is forcefully torn down by Android UI. This differs from iOS, where we do unmount the application on reloads.
This is a trade-off with performance, as we'll keep the JS thread alive slightly longer to complete shutdown, but it's the right call for correctness. It also only mainly affects development, as recreating the context is rare in production.
Repro steps:
```
useEffect(() => {
console.log('Playground useEffect invoked');
return () => {
console.log('Playground useEffect destructor invoked');
};
}, []);
```
Validate that when reloading the application, the second console.log is printed.
Changelog: [Android][Changed] React trees will be unmounted when the application is reloaded
Reviewed By: luluwu2032
Differential Revision: D45145520
fbshipit-source-id: a4dcd2ff4a8fc14cb0f276a5ef9afe21d1104735
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37039
ReactInstance is not meant to be used outside of bridgless package, this diff reduces its visibility.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D45197462
fbshipit-source-id: e2fa8ed145a05882d8f5384d4e4e17a3d6d984ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37042
BridgelessAtomicRef is only used in com.facebook.react.bridgeless, we reduce visibility to package only
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D45192193
fbshipit-source-id: 12253a2a8acd3c2edd550650f5f04a0346694b3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37047
We're seeing scenarios where `onRequestPermissionsResult` is being invoked but the current activity does not implement `PermissionAwareActivity`. This should not crash the app.
Changelog:
[Android][Fixed] - Fix crash when Android requests permission with activity that does not implement `PermissionAwareActivity`
Reviewed By: mdvacca
Differential Revision: D45203319
fbshipit-source-id: 4a6eb67ad67ae5c731c27301967b837b1286ccbb
Summary:
In the TurboModule interop layer, several modules are appearing as null. It's unclear why. We landed a few module resolution simplification diffs, to *attempt* to mitigate the problem: D45131297. But we're not sure if those diffs will be 100% successful.
So, this diff inserts two logs into the TurboModule system, for scenarios we know could lead to TurboModules being null. The hope: this helps us understand the actual problem, in case our earlier fix attempt (i.e: D45131297) fails.
Notes:
- These logs are temporary.
- These logs will only run in the TurboModule interop's test group.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45197703
fbshipit-source-id: 4401a6111492444cc4b405c52183d02df94c3828
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37032
Before, calling into global.turboModuleProxy would kickstart the module creation algorithm, **even if the module wasn't registered.**
Now, if the module isn't registered, TurboModuleManager will just early return null.
NOTE: When an unregistered module is requested from Java via TurboModuleManager.getModule(moduleName), the module algorithm will **still** run.
This fixes a bug:
- global.**native**ModuleProxy will no longer kickstart **turbo** module creation.
- global.**turbo**ModuleProxy will no longer kickstart **legacy** module creation.
NOTE: This **might** improve fb4a performance **a bit**: The TurboModule creation algorithm is *probably* expensive to run. 44 NativeModules are loaded at startup by Fb4a; 8 of them aren't registered with the app: [pastry](https://www.internalfb.com/phabricator/paste/view/P701125588?lines=2%2C4%2C5%2C7%2C9%2C16%2C18%2C24). Those 8 NativeModule creates will now shortcircuit to null faster.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45195578
fbshipit-source-id: cb09bdc059b3651b02447b7c2e37ef3f4ca2f92b
Summary:
These getNative* TurboModuleRegistry APIs make the TurboModuleManager harder to understand. They should have never been introduced.
Let's remove them for added clarity.
Changelog: [Android][Removed] - Remove TurboModuleManager.getNativeModule,getNativeModules,hasNativeModule
Reviewed By: mdvacca
Differential Revision: D45158032
fbshipit-source-id: 6f904dfe43fe7b2c215070a19f474acceddbf2f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36991
D15296732 added a byte to each YGNode exposed via private API, to stash random junk in. At the time, not adding to node size because of how fields ended up aligning. I'm not sure if this is still the case, but this is subject to change (e.g. adding a single extra flag).
There is a per-node "context" already that can store arbitrary data, and this reserved space isn't public, so this API is already a bit suspect.
The only place it is used is in instrumentation in fbandroid, enabled only in benchmarks, to store an enum to forward to QPL for what framework it thinks created the Yoga Node.
This is already broken for React Native (worked for Paper only), and afaict isn't used anywhere. But it also has little reason to be caching more information on the node (beyond maybe saving a couple memory accesses) since it derives this information from the node config already.
This removes the field.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D45137133
fbshipit-source-id: 75755b21102f7928b3ad947051c35b1a6566ef40
Summary:
changelog: [internal]
`_isUserTriggeredScrolling` must be NO when user interaction stops. This was not the case when user scrolled -> lifted finger but the scroll did not decelerate into position. The case with deceleration is handled in method `scrollViewDidEndDecelerating`.
Reviewed By: javache
Differential Revision: D45147325
fbshipit-source-id: 1b55dc708c4c7d6cffa917a822eb2b569b22dbb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37020
changelog: [internal]
if host view's position on screen changes, `RootShadowNode` has to be notified of this. Otherwise the state of UI is not correctly reflected in ShadowTree, leading to inconsistencies. For example, when trying to get views position in window, it won't be correct when hosting view isn't full screen.
Overriding `setFrame` only works for cases where it is hosting view's parent changing its position. But there are other cases where the position may change on the screen, like when hosting view's parent is moved by movable navigation bar. This does not affect frame of hosting view but it does change its position on the screen. To know about this event, we need to override `layoutSubviews`. `layoutSubviews` is called by UIKit whenever its internal flag `_needsLayout` is set to YES.
Reviewed By: javache
Differential Revision: D45122502
fbshipit-source-id: b7b1b08a8b3accffce7e3c71f7d19887caf6462f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37018
Just bumping Gradle version to the latest stable.
This brings configuration caching as stable, which is quite of a big deal.
Changelog:
[Android] [Changed] - Gradle to 8.1
Reviewed By: yungsters
Differential Revision: D45177537
fbshipit-source-id: 6a47208b69d5591d299451e5a610cc3f5e9afe66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36905
In this diff I'm deprecating EventBeatManager constructor that receives a Context as a parameter.
bypass-github-export-checks
changelog: [Android][Deprecated] deprecating EventBeatManager constructor that receives a Context as a parameter.
Reviewed By: fkgozali
Differential Revision: D44759827
fbshipit-source-id: cb117c26af0a43fe245f8778a55dfbea756b3ce6
Summary:
X-link: https://github.com/facebook/yoga/pull/1250
Pull Request resolved: https://github.com/facebook/react-native/pull/36988
BitUtils functions in Yoga are like bit fields, with more steps, and more error prone (you need to work with explicit offsets which can be tricky for anything variable length). Replace usage with a bitfield struct. Eventually I'd like to remove the BitUtils functions in general.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45133645
fbshipit-source-id: aa1430df5e2fb71ed9d2a5f5b1a35429b71c7069
Summary:
Changelog: [iOS][Breaking]
continuing getting rid of optional methods, but this does have a behavioral change. if the delegate does not provide the module instance, then we lazily create it. before we were returning nil, idk why. this will be a breaking change if you have any classes that conform to `RCTTurboModuleManagerDelegate`
#saynotoruntimechecks
Reviewed By: cipolleschi
Differential Revision: D45022139
fbshipit-source-id: 9635332caf3db7bb9306f99ee5c0d577091d38ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36968
Changelog: [iOS][Breaking]
we should be using `optional` never. this will be a breaking change if you have any class that conform to `RCTTurboModuleManagerDelegate`
#saynotoruntimechecks
Reviewed By: cipolleschi
Differential Revision: D45022003
fbshipit-source-id: d1b3cf72bae82070704f20de4558949189da462a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37008
Reduce Visibility of public methods that should be private
changelog: [Internal] internal
Reviewed By: luluwu2032
Differential Revision: D45153669
fbshipit-source-id: 2177a114eaa701d79a21d8a25bd299bf681dc4b8
Summary:
X-link: https://github.com/facebook/yoga/pull/1251
Pull Request resolved: https://github.com/facebook/react-native/pull/36990
YGNode::setConfig was deprecated as part of D15416474 in an apparent goal to remove config pointers per-Node.
While I don't know the history of the motivation here, these config pointers were never removed, and we will be doubling down on per-node configs for StrictLayout, so we will want to undeprecate this.
This also exposes functions to the public C ABI, but I didn't spend the effort to create language projections for it.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45133646
fbshipit-source-id: 2bb15c4825717793529cdad8542447d11e723e35
Summary:
Upgrades React Native to `deprecated-react-native-prop-types@4.1.0`, which includes many of the new prop types in React Native v0.72.
See: https://github.com/facebook/react-native-deprecated-modules/blob/main/deprecated-react-native-prop-types/CHANGELOG.md
Changelog:
[General][Changed] - Upgrade to deprecated-react-native-prop-types@4.1.0
Reviewed By: rickhanlonii
Differential Revision: D45155955
fbshipit-source-id: 36e715c2338b667755bd1e522b7d5a2611103779
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36980
With the TurboModule interop layer, some modules aren't being loaded at all. This logging will help us root cause the problem: is the issue with the TurboModule system, or with instantiating a particular module.
Changelog: [Internal]
Reviewed By: cortinico, mdvacca
Differential Revision: D45102812
fbshipit-source-id: 5c5f55d5857c694270a83c38b68cae0fdb2c3b50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36986
global.nativeModuleProxy and global.__turboModuleProxy should not share the same cache.
Otherwise, global.nativeModuleProxy could return TurboModules, and global.__turboModuleProxy could return legacy native modules.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45131296
fbshipit-source-id: 472059dc95d760a5eb8fc376606b30e614ee86c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36985
This diff simplifies TurboModuleManagerDelegate. Now, it doesn't do any filtering.
What TurboModuleManagerDelegate does:
- If the TurboModule interop layer is on, getLegacyModule(moduleName) starts returning legacy modules.
- If the TurboModule interop layer is off, getLegacyModule(moduleName) returns null.
This should help with T144183369. In that crash, some native modules are returned as null. And complicated filtering could be a contributor to that problem. So, simplifying filtering might mitigate that issue.
Even if it doesn't, this makes the TurboModuleManager easier to understand, which makes root causing/mitigating that problem easier.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45131297
fbshipit-source-id: 9e37804e09c9f04ab0610f5b444574ae65c9d638
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36994
We already run changelog validation internally which has specific exemptions for codemods and dirsynced directories. Do not run twice, now that we need to export diffs.
An alternative solution would be to port the logic to the OSS changelog generator and stop running the internal one, but that would increase latency, and we have made fixes to the internal once as recent as two weeks ago in D44746795.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D45135111
fbshipit-source-id: e23c2613b183f75a148d1b38b31c259acc9c9fc5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36998
For performance entries that have the same start/end time it makes more sense to report them back to `PerformanceObserver` in the same order they were logged.
This kind of determinism is arguably better both in terms of API, and from the point of view of testing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D45142500
fbshipit-source-id: 77ff0093bead45dc2f15efc4b903dc181927565a
Stephanie Nicholson
Pranav Yadav
Nick Gerleman
Facebook Community Bot
Krystof Woldrich
Blake Friedman
Pieter De Baets
Antoine Doubovetzky
Moti Zilberman
David Vacca
Tim Yung
Ramanpreet Nara
Samuel Susla
Ruslan Shestopalyuk
Nicola Corti
Christoph Purrer
Phillip Pan
Oleksandr Melnykov
yaqi.liu
