Summary:
This diff adds `RedBoxSurfaceDelegate` to replace existing logic in `DevSupportManagerBase` to abstract how we show/hide the RedBox surface. The delegate will wrap a RedBoxDialog instance, which is used to show/hide the dialog for default behavior (when there is no surface delegate for redbox got provided).
I also updated the interface for delegate to accomodate new use cases:
- Add `isShowing` for the `SurfaceDelegate`
- Add a list of getters for `DevSupportManager` for data access in the delegate
- (Update 2/7) Separate Dialog from `RedBoxDialog`, and re-named it to `RedBoxContentView`. This is to make it clear that the delegate is responsible to provide actual surface implementation (Dialog). The content view is meant to be shared.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D33987835
fbshipit-source-id: 57c20648e7f2ec8238963feca27ccd5518e7931d
Summary:
Not setting locale for language/country neutral operation may cause bug depending on the default locale.
See https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#ROOT
Note: I am just searching for toLowerCase() and toUppercase() in my project's dependencies and send the same PR, in order to just be considered. Although I've seen the lack of explicit locale has caused issues for us, I am not sure if react-native is actually affected. I haven't checked for `String.format()` yet.
Example related issue: joltup/rn-fetch-blob#573
## Changelog
[Android] [Fixed] - Use root locale when converting string case.
Pull Request resolved: https://github.com/facebook/react-native/pull/33028
Reviewed By: ShikaSD
Differential Revision: D33943446
Pulled By: cortinico
fbshipit-source-id: d5be9392ea7c21a33436acac5b5e8c50b7c7e31e
Summary:
This diff separates the content view creation logic from existing `RedBoxDialog` logic. After the change, `RedBoxDialog` is no longer a subclass of `Dialog`, but behaves like a dialog with forwarding pattern to delegate dialog API to internal member. This will keep the APIs consistent with dependent components.
The motivation of the change is to make the content view reusable. This is important in VR surface where we don't have activities and necessary implementations for Dialog to show.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D34016503
fbshipit-source-id: 261594bda9f6fb2d83764a1e5ec2e9e60d8d39a3
Summary:
We put the `:interfaces` target on the dependencies list for `:devsupport` target in the [BUCK file](https://fburl.com/code/lrr1c0pn). In the following diffs I will need to put the interface [`/devsupport/RedBoxHandler`](https://fburl.com/code/v53euvps) on to [`/devsupport/interfaces/DevSupportManager`](https://fburl.com/code/k8gwxa0f). This violates the dependency rule.
Since `RedBoxHandler` is an interface, I moved it to the interfaces list in this diff to unblock.
Changelog:
[Android][Internal]
Reviewed By: yungsters
Differential Revision: D33987834
fbshipit-source-id: 77a1ee14bd10c6bbaac2ee465ae7050e99ed0399
Summary:
This diff introduces a new interface named `SurfaceDelegate`. The interface abstracts the API for interacting with a surface, which is required for platforms other than mobile to implement how it wants to show and hide a surface. For existing Mobile use cases, the `LogBoxDialogSurfaceDelegate` is provided as a fallback solution so everything still works.
Changelog:
[Android][Added] - Add SurfaceDelegate abstraction to support interaction in multiple platforms and provide default implementation in LogBoxModule
Reviewed By: mdvacca
Differential Revision: D31132285
fbshipit-source-id: 13315a8bc5b7bcaee9b5e53ef5c6f6cc8cb01f31
Summary:
to open possibilities for some DX enhancement, the pr introduces `DevSupportManagerFactory` customization. applications could implement a different DevSupportManager in ReactNativeHost.
## Changelog
[Internal] [Added] - Support custom DevSupportManager
Pull Request resolved: https://github.com/facebook/react-native/pull/31841
Test Plan: this pr just introduces some new interfaces and should not break existing functionalities.
Reviewed By: RSNara
Differential Revision: D30878134
Pulled By: yungsters
fbshipit-source-id: ccdf798caa322b07a876da8312b97002da057388
Summary:
Try to reuse currentActivity when the new context from "mReactInstanceDevHelper.getCurrentActivity()" is null to fix "Unable to launch redbox because react activity is not available..."
Changelog:
[Android][Fixed] - Fix currentActivity being null when launching Redbox
Reviewed By: philIip
Differential Revision: D30942434
fbshipit-source-id: faf03390adc545376f3cec223eac5a16bf8233ea
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
Changelog: [Internal]
Separate the functionality of the isPackagerRunning() function into a new class PackagerStatusCheck with the intention of being able to use this without needing a DevServerHelper
Reviewed By: makovkastar, ShikaSD
Differential Revision: D29933318
fbshipit-source-id: d708bb987b08634015d6ee6b6c8989faba416c5a
Summary:
Rationale:
- This makes the element inspector button consistent with the Fast Refresh, Perf Monitor and other buttons in the DevMenu
- This makes the button more informative
Changelog: [Android][Changed] Rename the "Toggle Inspector" DevMenu item to "Hide/Show Element Inspector"
Reviewed By: JoshuaGross
Differential Revision: D29146871
fbshipit-source-id: 8e8c19217ea2ff2f1d176521aa22200058e7e643
Summary:
Before the DevMenu would just open up as a DialogBox. After this change, the DialogBox will have a title. This should help distinguish between the Bridgeless DevMenu and the Bridge DevMenu.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29071185
fbshipit-source-id: 72533f10b73b36cd890fe152c6de901c867159f2
Summary:
With bridgeless mode enabled, there can be two instances of DevSupportManager. Previously, both of them wrote to the same files on disk. After this change, each instance will write the bundle to different files on disk.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29068794
fbshipit-source-id: 67270be17d084cc89ab618ea54f729f9b595b5f7
Summary:
Google Chrome debugging is only supported by the bridge. So, it makes sense to move it to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29031514
fbshipit-source-id: 4d6b6bb3bc298be5fe4d9f96c0d019676fe256db
Summary:
## Rationale
The public methods of PackagerCommandListener should not be a part of the public API of DevSupportManagerBase. It's cleaner to just create a new PackagerCommandListener object inline, when we need it. This way, there're are less methods to think about when reasoning about the public API of DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006835
fbshipit-source-id: 0eea86c22e7d676c94d29b240a1f39955d8216ab
Summary:
## Rationale
This reduces the surface area of DevSupportManager's public API.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006836
fbshipit-source-id: 579364f6c556b8588f3b6bac79df3deb244a92e5
Summary:
## Rationale
This DevSupportManagerBase constructor isn't used anywhere, aside from VeniceDevSupportManager. Even in VeniceDevSupportManager, we should use the more specific constructor, because it informs readers of the class what specifically is being nullified in the base class. So, this diff gets rid of the smaller arity constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004542
fbshipit-source-id: 74e20db93cf1871a364bf228dc089cd7d124297f
Summary:
## Rationale
DevSupportManagerBase.handleReloadJS() implements reloads for the bridge. Therefore, it's best to move this method to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004541
fbshipit-source-id: f77244e9c44cd442e7e0ab2845f78d699b143e66
Summary:
## Rationale
Throughout DevSupportManagerBase, we show/hide the DevLoadingView and simultaneously write to the `mDevLoadingViewVisible` boolean. This diff pulls all those boolean writes into methods, so that subclasses of DevSupportManagerBase can show/hide the DevLoadingView without accessing the boolean directly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004062
fbshipit-source-id: d54d79701e31f9ac8d1d1d44019199718fe1c8c0
Summary:
## Rationale
DevSupportManagerBase.loadSplitBundleFromServer() uses the bridge. So, it's best to move it to DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004064
fbshipit-source-id: 9acfb769d57a44ee4871e1997ff0950c3d66b757
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
