Summary:
Changelog: [internal]
This change had to be reverted because it caused some issues internally at Facebook. After we solved those we re-applied the changes but this also has issues in OSS apps. Specifically, the option in Metro to inject modules to execute before the EntryPoint (in this case `InitializeCore`) doesn't work if those modules aren't part of the bundle in the first place.
This reverts again so we can think about a long-term solution for this.
Original commit changeset: ba145a30ead5
Reviewed By: ShikaSD
Differential Revision: D31825736
fbshipit-source-id: 393b3d5d2a726951a9ac386dc2b1c19ef4a916a5
Summary:
This module is imported by all flavors of the React Native renderers (dev/prod, Fabric/Paper, etc.), which itself imports `InitializeCore`. This is effectively a no-op in most React Native apps because Metro adds it as a module to execute before the entrypoint of the bundle.
This import would be harmless if all React Native apps included all polyfills and globals, but some of them don't want to include everything and instead of importing `InitializeCore` they import individual setup functions (like `setupXhr`). Having this automatic import in the renderer defeats that purpose (most importantly for app size), so we should remove it.
The main motivation for this change is to increase the number (and spec-compliance) of Web APIs that are supported out of the box without adding that cost to apps that choose not to use some of them (see https://github.com/facebook/react-native/pull/30188#issuecomment-929352747).
Changelog: [General][Removed] Breaking: Removed initialization of React Native polyfills and global variables from React renderers.
Note: this will only be a breaking change for apps not using the React Native CLI, Expo nor have a Metro configuration that executes `InitializeCore` automatically before the bundle EntryPoint.
Reviewed By: yungsters
Differential Revision: D31472153
fbshipit-source-id: 92eb113c83f77dbe414869fbce152a22f3617dcb
Summary:
This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.
Motivation: The main goal is to move one step closer to turning off Haste for RN (https://github.com/facebook/react-native/issues/24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.
Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.
There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.
## Changelog
[General] [Changed] - Add a private interface (do not use) between the renderer and RN
Pull Request resolved: https://github.com/facebook/react-native/pull/24782
Differential Revision: D15413477
Pulled By: cpojer
fbshipit-source-id: 3766ad4cf129fad0c82f0ddc7a485a4ba313b2c4
Andres Suarez
Rubén Norte
Oleksandr Melnykov
James Ide