Summary:
## Rationale
- AsyncDevSupportManager.loadSplitBundleFromServer() is an override of DevSupportManager.loadSplitBundleFromServer(), which is used by the bridge. However, AsyncDevSupportManager.loadJSBundleFromServer() has no bridge analogue. This is confusing: Are the methods in AsyncDevSupportManager Venice overrides for bridge related methods? It's easy to think yes, but the answer is no.
- AsyncDevSupportManager.loadJSBundleFromServer() is an additional layer of indirection that provides very little value: all it does it create the JSBundleLoader, and call onReactContextCreated. However, it does so in 11 lines of very confusing code.
A discussion we don't have to have now: Inheritance hierarchies are very difficult to understand and de-tangle. So, instead of using inheritance to make DevSupportManager work with Venice (via AsyncDevSupportManager), should we just refactor DevSupportManager so that it can be customized to work with Venice?
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27577591
fbshipit-source-id: b64dcd65e9a7c85b89443d860d441a0635547916
Summary:
Sometimes ```hasActiveCatalystInstance()``` is used to check if it's safe to access the CatalystInstance, which will still crash in Venice.
Previously we mitigate this by changing ```reactContext.hasActiveCatalystInstance()``` to ```reactContext.hasActiveCatalystInstance() || reactContext.isBridgeless()```.
To solve this for all and good the plan is:
1, Rename ```hasActiveCatalystInstance()``` to ```hasActiveReactInstance()``` so it won't sounds like CatalystInstance-only.
2, Implement hasActiveReactInstance() for Venice. D27343867
3, Remove previous mitigation. D27343952
This diff is the first step, by xbgs there are **58** non-generated callsites of ```hasActiveCatalystInstance()``` in code base which are all renamed in this diff.
Changelog:
[Android][Changed] - Rename "hasActiveCatalystInstance" to "hasActiveReactInstance"
Reviewed By: mdvacca
Differential Revision: D27335055
fbshipit-source-id: 5b8ff5e09b79a492e910bb8f197e70fa1360bcef
Summary:
In DevSupportManagerBase.java->updateLastErrorInfo(), errorType was not recorded like errorMessage and errorStack, we could either remove errorType as a parameter or recorded it for future use. This diff recorded it since it would make the error info complete.
Changelog:
[Android][Changed] - Record latest error type in dev support
Reviewed By: PeteTheHeat
Differential Revision: D26884647
fbshipit-source-id: 712d82667bdc4b3410f4c83a3df9a456af6d9061
Summary:
This diff migrates all NativeModules away from onCatalystInstanceDestroy() to the invalidate() method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871595
fbshipit-source-id: 132f6b75e485361835769a2b53bc742eefa47b59
Summary:
## Description
Suppose this was the codegen declaration before:
```
rn_library(
name = "FooModule",
native_module_spec_name = "FBReactNativeSpec",
codegen_modules = True,
# ...
)
```
Previously, this would generate the following BUCK targets:
- generated_objcpp_modules-FooModuleApple
- generated_java_modules-FooModuleAndroid
- generated_java_modules-FooModule-jniAndroid
## Changes
We will now generate:
- FBReactNativeSpecApple
- FBReactNativeSpecAndroid
- FBReactNativeSpec-jniAndroid
This matches the naming scheme of the old codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25680224
fbshipit-source-id: 617ac18fd915f3277f6bd98072d147f20fb193e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
This moves all deps on the checked in fbreact/specs files to use the generated output (during build time) instead.
TLDR:
`react_native_target("java/com/facebook/fbreact/specs:FBReactNativeSpec")` ==> `react_native_root_target("Libraries:generated_java_modules-FBReactNativeSpec")`
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24520293
fbshipit-source-id: 3fb34f172f1ab89b7198dfb4fccf605fbc32d660
Summary:
1, Fix the redbox on Pokes route when running Metro with Venice enabled.
2, Fix CrashReactRoute stucking with the loading indicator issue.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D22477500
fbshipit-source-id: 65e908ac360e031e5f3562a21c09cb0d7ddaf7a0
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary: This diff updates the loading banner text and color on Android to match its style on iOS.
Differential Revision: D22066823
fbshipit-source-id: 7f8d6cf1a6c4c48babe919995044978d7a81c674
Summary:
Removing logs related to T62192299 that we don't need anymore.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21773629
fbshipit-source-id: d16c01f87be3ed7512fe90b6e261b4c7efbd3068
Summary:
Adds the package name (Android) / bundle ID (iOS) as a new URL parameter named `app` in the bundle URL. This currently has no effect on Metro, which will ignore it for bundling / caching purposes.
Changelog: [General] - Add package name / bundle ID to bundle URL in development
Reviewed By: cpojer
Differential Revision: D21429764
fbshipit-source-id: 394fe50dba72219f7594ebeac9486a8264a836a6
Summary:
This is the codemod portion of the parent diff.
I modified all call-sites to `ReactContext.getNativeModule` to do a null check on the returned NativeModule.
Changelog:
[Android][Fixed] - Check if NativeModules returned from CatalystInstanceImpl.getNativeModule are null before using them.
Reviewed By: JoshuaGross
Differential Revision: D21272028
fbshipit-source-id: 6bd16c6bf30605f2dfdf4c481352063712965342
Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20784279
fbshipit-source-id: caecdace00007224692d994a75c106842c8b2acb
Summary:
This is the first of three PRs related to enabling multi-bundle support in React Native. More details, motivation and reasoning behind it can be found in RFC [here](https://github.com/react-native-community/discussions-and-proposals/issues/152).
Logic responsible for installing globals was pulled out from `loadApplicationScript` to `initializeRuntime` since it should be ran only once, what was left was renamed to `loadBundle`.
It's based on dratwas work from [here](https://github.com/callstack/react-native/tree/feat/multibundle/split-load-application), but applied to current `master` to avoid rebasing 3-months old branch and issues that come with that.
## Changelog
[Internal] [Changed] - split `loadApplicationScript` into `initializeRuntime` and `loadBundle` to enable multi-bundle support in the future
Pull Request resolved: https://github.com/facebook/react-native/pull/27844
Test Plan: Initialized new RN app with CLI, set RN to build from source and verified the still app builds and runs OK using code from this branch.
Reviewed By: rickhanlonii
Differential Revision: D19888605
Pulled By: ejanzer
fbshipit-source-id: 24ace48ffe8978796591fe7c6cf53a61b127cce6
Summary:
## Overview
This diff is an RFC to port a logging feature from iOS to Android.
Changelog: [Internal]
## Motivation
On iOS we have the following log functions and behaviors available for logging native warnings and errors:
- **Warnings** (`RCTLogWarn`)
- Log level 'warn' to console
- Display warning in LogBox
- **Errors** (`RCTLogError`)
- Log level 'error' to console
- Display a native RedBox (needs converted to show a LogBox if available)
- **Logs**
- We also have `RCTLog`, `RCTTrace`, `RCTAdvice`, `RCTInfo`, which just log to the console.
In Java, we have:
- **Warnings**
- **None**, added in this diff
- **Errors** (`DevSupportManager.showNewJavaError`)
- Log level 'error' to console with `FLog.e`
- Display a native RedBox (needs converted to show a LogBox if available
- **Logs**
- `ReactSoftException` (crashes the app??)
- `ReactNoCrashSoftException` (only logs??)
- Others?
## Details
This diff adds a method to pair with `RCTLogWarn`, `DevSupportManager.showNewJavaWarning`, which will log to the console and show a LogBox warning if LogBox is available.
## Concerns
I have a few concerns/questions about the state of logging on Android:
- Should/can we move all of the logging to it's own class, like how RCTLog works?
- Why does some logging happen on DevSupportManager and some in other classes?
- If we moved it all to it's own class, how could we access the reactContext to call the RCTLog JS module
Reviewed By: JoshuaGross
Differential Revision: D20056394
fbshipit-source-id: 32d57e300685e46da8039fc77cb22b4084acf81a
Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
Do we need this? Is it possible for any of these codepaths to execute in production? If so, it would be nice to avoid NPEs or even scheduling work on the UI thread.
Maybe we want to add soft exception logging for if these paths are called?
Changelog: [Internal] make sure LogBox does even less work when it's not hooked up
Reviewed By: rickhanlonii
Differential Revision: D20156812
fbshipit-source-id: ba9faedcb3b0951e6913724ca99549dc2d16237e
Summary:
This is step 3 in creating a new DevSupportManager with a better async API for loading the JS bundle from Metro.
Right now DevSupportManagerImpl calls a method on its ReactInstanceManagerDevHelper delegate when the JS bundle is done being downloaded from the server. However, I want to move to a callback-based method for bridgeless mode (similar to packager status). In this diff, I'm adding a protected method that uses a callback, and then calling that from `reloadJSFromServer` with a callback that calls the delegate, to preserve existing behavior.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19871102
fbshipit-source-id: 2dbb6b91c5b927df86c3db42aa11e080d57ea78e
Summary:
This is the second step in creating a new DevSupportManager impl with more async-friendly APIs for bundle loading, which I'll use in bridgeless mode. This diff creates a new interface, AsyncDevSupportManager, and two implementations, mirroring what we currently have.
This new interface doesn't define any methods yet.
Changelog: [Android][Changed] Specify DevSupportManager.setPackagerLocationCustomizer in DevSupportManager impls
Reviewed By: mdvacca
Differential Revision: D19870812
fbshipit-source-id: 042a43e1a3055aba6d7325f948060300b5bf17f3
Summary:
This is the first step for adding my own async APIs for DevSupportManager to use in bridgeless mode.
To avoid having to add these APIs to the DevSupportManager interface + both of its implementations, I'm instead splitting DevSupportManager into a base class + final impl so I can more easily share logic with the new impl I'll create.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19846619
fbshipit-source-id: c67b0231f4e6581fb484f9a4899ed0b7f08fb684
Summary:
We must use FLog instead of android.util.log, this diff moves the current callsites of android.util.log to FLog
changeLog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19884741
fbshipit-source-id: 300f7d691961aa51f0b525c37da7ae3d64fe5131
Summary:
This converts all NativeModules excluding the following into TurboModules:
```
// Deleted
"fbsource/fbandroid/java/com/facebook/catalyst/modules/relaynativecache/RelayNativeCacheReaderModule.java"
// Owners of FBC will migrate these by themselves
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/i18n/FBCi18nAssetsModule.java"
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/react/CellScanResultsModule.java"
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/react/WiFiScanResultsModule.java"
// Don't have Buck owners
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBAccessTokenModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBGraphRequestModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBLoginManagerModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBShareAPIModule.java"
"fbsource/xplat/intl/oss-fbt/__github__/react-native-fbt-android-native-module/android/src/main/java/com/reactlibrary/FbtAndroidNativeModule.java"
```
This should conclude the Android TurboModule migration.
Changelog:
[Android][Added] - Make remaining NativeModules TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D19383442
fbshipit-source-id: 71beaee087f6436b197a65f0d68527d9964bb6ce
Summary:
For every untyped NativeModule Java file, we ensure that its owner depends on the owner of its JS spec.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19382937
fbshipit-source-id: 0a1d840bff2f9e8db0f06c910448e9b25415d18c
Summary:
## Problem
`DebugCorePackage` is a `TurboReactPackage`. To register a `TurboReactPackage`s NativeModules, the `NativeModuleRegistryBuilder` loops over all `ReactModuleInfo`s in the package's auto-generated `ReactModuleInfo` list. This list is generated from the `ReactModuleList` annotation of the package using our annotation processors. Because `JSDevSupport` was in its package's `ReactModuleList` annotation, we generated a `ReactModuleInfo` object for it. Therefore, `NativeModuleRegistryBuilder` registered `JSDevSupport` twice (once in `DebugCorePackage` and twice in `Fb4aReactPackage`).
## How did this work before?
`JSDevSupport` was always a part of the `ReactModuleList` annotation of `DebugCorePackage`. However, before D18974084 landed, there were two key things that made this work:
1. `DebugCorePackage` was a `LazyReactPackage`,
2. The `DebugCorePackage.getNativeModules()` did not return a `ModuleHolder` for `JSDevSupport`.
For `LazyReactPackage`s, `NativeModuleRegistryBuilder` calls `LazyReactPackage.getNativeModuleIterator()` to register NativeModules. The iterator returned from `LazyReactPackage.getNativeModuleIterator()`, in this case, loops over the NativeModules returned from `DebugCorePackage.getNativeModules()`. Therefore, we don't register any NativeModules that aren't in `DebugCorePackage.getNativeModules()`. Since `DebugCorePackage.getNativeModules()` didn't contain `JSDevSupport`, it wasn't registered for the second time.
Changelog:
[Android][Fixed] - Unregister JSDevSupport from DebugCorePackage
Reviewed By: ejanzer
Differential Revision: D19187664
fbshipit-source-id: 34141c60542179567d75705937ba09ec8a3dfc2b
Summary:
@public
With this, you can determine the packager location at run time before we even try to load the bundle.
Changelog: [Android] [Added] - Packager location can be determined at run time
Reviewed By: makovkastar
Differential Revision: D18940087
fbshipit-source-id: fac99f28e119a4e7a2961b5504cfe7d2d409e8f7
Summary:
This diff fixes the redbox that is currently affecting initial render of RN Android apps
More details: https://fb.workplace.com/groups/rn.support/permalink/3125289967519597/
Changelog: [internal]
Reviewed By: JoshuaGross, ejanzer
Differential Revision: D19132862
fbshipit-source-id: 6833a32bae2e0dda254f1bd09520551aa41fa822
Summary:
All these NativeModules are now: (1) type-safe, (2) TurboModule-compatible.
**Note:** We still need to update `{Catalyst,Work,Fb4a}TurboModuleManagerDelegate` to understand these TurboModules. I'll most likely write up that diff and stack this one on top of it.
Changelog:
[Android][Added] - Make NativeModules TurboModule-compatible
Reviewed By: mdvacca
Differential Revision: D18888735
fbshipit-source-id: 34df64dc70e3f3a0a0303c049861205f9d3fd2ed
Summary:
The NativeModules in DebugCorePackage are now TurboModule-compatible. Therefore, we must make this extend `TurboReactPackage`.
Changelog:
[Internal] - Make DebugCorePackage a TurboReactPackage
Reviewed By: fkgozali
Differential Revision: D18974084
fbshipit-source-id: 648b54fefe7f8952666d5a23a9d81cc6bb167b31
Summary:
This diff adds a NativeLogBox module implementation on Android to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a React rootview and render it.
- show: will add the rootview to a dialog and display the dialog.
- hide: will remove the rootview from it's parent, dismiss the dialog, and release the reference to the activity to prevent leaks.
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the rootview with the `initialize` function so that it's warm by the time the dialog needs to render.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18768517
fbshipit-source-id: 2510d6c186ccf73153ef9372c736c9e0c71bbc7d
Summary:
## Step 1
I'm going to make every Java NativeModule type-safe and TurboModule-compatible. The first step is to make sure that every type-unsafe NativeModule has a dependency on its spec's codegen target.
## Input
Module -> owner(Module): P123320255
Module -> name(Module): P123320256
Module -> owner(spec(name(Module))): P123320257
### Excluded NativeModules
NativeModules without Specs: P123320644
Java only NativeModules: P123320645
Changelog:
[Internal] - Add buck dependencies for NativeModule specs
Reviewed By: mdvacca
Differential Revision: D18781629
fbshipit-source-id: 89f39017b8224355d9d7b43bf6c162b0957760ee
Summary:
Simplify the API of `getReactApplicationContextIfActiveOrWarn`. We don't need to pass so much information into this method to collect good SoftExceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18134400
fbshipit-source-id: 0a250ab0252a44121f3339a31506a0a6c4c7cd35
Summary:
When testing out the NetworkOverlay, I noticed that we were creating a lot of WebSocket connections for localhost:8097. Rick found that this is because we're trying to connect to React devtools every 2 seconds: https://github.com/facebook/react/blob/master/packages/react-devtools-core/src/backend.js#L67 and it appears we create a new WebSocket every time.
Dan suggested that we use opening the dev menu as a trigger for attempting to connect to React devtools. This diff uses RCTNativeAppEventEmitter to emit an event from native when the dev menu/dialog is shown, and listening to that event in JS to attempt to connect to devtools.
I'm also making the change of passing in a websocket instead of just passing in the host + port; this way it will only attempt to connect once on each call to `connectToDevTools` (otherwise, we would attempt to reconnect every 2 seconds as soon as the dev menu is opened, and then the next time the menu is opened we'd so start that *again*, and so on - I could have it keep track of whether it's already connecting and avoid doing it again, but this is easier and should be sufficient, I think).
We should probably also update the suggested troubleshooting tips on the devtools page to reflect this change, so that people don't get confused.
Changelog: [General] [Fixed] Fix issue where we attempt to connect to React devtools every 2 seconds
Reviewed By: mmmulani
Differential Revision: D17919808
fbshipit-source-id: 4658d995c274574d22f2f54ea06d7f29ef2f54dc
Summary:
Renders frames in RedBox in a greyed-out style when their `collapse` field is set to `true`. This avoids outright hiding information in the stack trace while still drawing attention to frames that are likely to be more meaningful.
Changelog: [General] [Changed] - Render collapsed JavaScript frames in RedBox
Reviewed By: rickhanlonii
Differential Revision: D18039438
fbshipit-source-id: 527588f11c0bff495842be7036cd1293bab65eb9
Summary:
In D18032458 we introduce `getReactApplicationContextIfActiveOrWarn`. In this diff, modules that access a JS or Native module through ReactApplicationContext need to check if the CatalystInstance is still alive before continuing.
Changelog: [Internal]
Reviewed By: furdei
Differential Revision: D18032788
fbshipit-source-id: 5152783afd0b93b8ce0970fe4a509ea71396a54a
