Summary:
If redbox flag is disabled, don't initialize LogBox window even if the native module exists. This makes the module noop.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18927309
fbshipit-source-id: 3dc6c08ed537925594cabf77d1142568d47132e9
Summary:
This diff extends the UIManagerHelper class to expose the EventDispatcher associated to a tag / UImanagerType
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862863
fbshipit-source-id: 14ce7a6a33f20a94a6296320924dbe3544eadd85
Summary:
This diff exposes the getJSIModule on the ReactContext class.
This class already has methods to obtain NativeModules and JSModules, it make sense to expose the getJSIModule method too.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862858
fbshipit-source-id: 95fe48c065266060c96fc40a002041ba398b3134
Summary:
This method exposes a method to ReactContext to determine if we are running in Bridgeless mode or not
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901149
fbshipit-source-id: bdd5ba747381f3bde5f592276b42244ca01ccbb9
Summary:
This diff promotes the UIManagerModule.getEventDispatcher() to the interface UIManager and it implements this method in FabricUIManager class.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862862
fbshipit-source-id: 424f0e601ed1807dbd5d33048daf7dc3bb200dcd
Summary:
`NativeImageEditor` doesn't export any constants. Therefore, `ImageEditingManager` doesn't need a `getConstants()` method. In a subsequent diff (D18888735), I rename all `ReactMethod getConstants()` methods to `Override getTypedExportedConstants()`. This raises an error because the spec for `ImageEditingManager` doesn't contain a `getTypedExportedConstants()` method.
Changelog:
[Internal] - Delete getConstants() from ImageEditingManager
Reviewed By: fkgozali
Differential Revision: D18909419
fbshipit-source-id: 7e4f84f102068aa44bb3d267c66a60c0d0d27404
Summary:
`JSDevSupport.onSuccess` is called in `JSDevSupportModule.getJSHierarchy`:
```
const JSDevSupportModule = {
getJSHierarchy: function(tag: number) {
try {
const {
computeComponentStackForErrorReporting,
} = ReactNative.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED;
const componentStack = computeComponentStackForErrorReporting(tag);
if (!componentStack) {
JSDevSupport.onFailure(
JSDevSupport.ERROR_CODE_VIEW_NOT_FOUND,
"Component stack doesn't exist for tag " + tag,
);
} else {
JSDevSupport.onSuccess(componentStack);
}
} catch (e) {
JSDevSupport.onFailure(JSDevSupport.ERROR_CODE_EXCEPTION, e.message);
}
},
};
```
If you look at the implementation of `computeComponentStackForErrorReporting`, it returns a `string`. The Java NativeModule also accepts a `String` for the argument to `JSDevSupport.onSuccess`. So, I've changed the `NativeJSDevSupport.onSuccess` method signature to match the native implementation (i.e: accept a string).
Changelog:
[General] [Fixed] - Correct argument types of NativeJSDevSupport.onSuccess
Reviewed By: fkgozali
Differential Revision: D18908306
fbshipit-source-id: 1c9a5c6fe5b3a81b25baed520e586ebf7e2514f8
Summary:
This diff fixes an issue where symbolicated logs were getting stuck in a "pending" state if the timeout occurred before symbolication finished.
Changelog: [Internal]
Reviewed By: sahrens
Differential Revision: D18894154
fbshipit-source-id: ed225962468f67aef40e430aa798f8d426d31027
Summary:
This diff adds a new `unstable_enableLogBox` function to opt-into the new LogBox experience. If LogBox is not enabled early enough, we show an error with instructions.
With this, LogBox can be enabled with:
```
require('react-native').unstable_enableLogBox();
```
Changelog: [General] [Adds] unstable_enableLogBox
Reviewed By: zackargyle, rubennorte
Differential Revision: D18808940
fbshipit-source-id: 4b0234ddc4d1646515bf63110d5b02133780512e
Summary:
Apologies for the large diff, it was difficult to break down.
This diff is a major refactor of LogBox that:
- Separates LogBoxNotification and LogBoxInspector
- Moves them each to their own container
- Updates AppContainer to only render the notification
- Updates the native logbox root to render the inspector
- Adds withSubscription HOC to manage subscribing to LogBoxData
- Simplifies LogBox to export an object instead of a component
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750011
fbshipit-source-id: 639885d29e55e125892d1c2b6bbf2826f27d78db
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:
This diff adds a NativeLogBox module implementation on iOS 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 hidden window (the way redbox does) and render the LogBox to it
- show: will show the window
- hide: will hide the window
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the window with the `initialize` function so that it's warm by the time LogBox needs to render.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D18750008
fbshipit-source-id: 013e55ded55c8572bb08e0219ff4cd0060ebe0da
Summary:
This diff stubs out registering LogBox as a renderable component. In later diffs, we'll render this component on the native side.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750005
fbshipit-source-id: 4db082ca2104731641d2d10de1ba83a318ab44fb
Summary:
Having those arguments optional does not really make anything easier to use; on another side that makes it hard finding problems caused by missing that parameter.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18797337
fbshipit-source-id: c119b8f6a03994072edb45e39337e33b0f8b602f
Summary:
NativeComponent as a type isn't needed now that we have HostComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18873494
fbshipit-source-id: 5ba3fa25537f8249c80c2303dcdb380e3b6b0ac5
Summary:
Turns on the exact-by-default flag in xplat/js and gets rid of the implicit inexact object lint, which has no effect when exact-by-default is on.
Will land this on Monday along with an announcement post.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D18863276
fbshipit-source-id: 07a31e957bea1d1e053e8fa5975fdb1b6da1bdc4
Summary:
Introduced 2 helper functions to toggle image instrumentation/logging (not in this diff) so that gating check is more efficient and easy to access across RN iOS core.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18597208
fbshipit-source-id: 0b22031802ab020b16d6fb63e52461cf80a37ab5
Summary:
`accessibilityTraits` was missing, this diff adds it.
Also there is a name mis match, in javascript it is called `accessibilityRole`.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18857668
fbshipit-source-id: 10656e8fb4e8c1d771a72c7f354b845e41cfc313
Summary:
UpdateLocalData and UpdateState return an `extra data` object, which in the case of TextInput contains padding. In Paper, the padding was always set on this object; in Fabric, it generally is not. However, the ViewManager was unconditionally setting the padding on the view, regardless of whether or not padding was set. We just check the padding values before setting now. This fixes an issue where the padding would be reset when the user started typing in Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18875261
fbshipit-source-id: d7cb87c07f47ab522e32cd34a4ca6ed5fea2e832
Summary:
This temporarily disables an `assert` in `ComponentDescriptorProviderRegistry`. The `assert` only suggests that the call to the class is redundant, so it's safe to just remove it for now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D18878273
fbshipit-source-id: 007a2c6f62f858126912b7e54a1098e6f4c25a16
Summary:
Read more about this in D18848583 (where it's implemented for iOS). This diff enables that for Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18869823
fbshipit-source-id: ebdc863ec07268119d1cbbb911760532bb28ee04
Summary:
This component no longer has any internal callsites and was never exposed in the public API!
Changelog:
[General][Removed] Removing experimental IncrementalPresenter component
Reviewed By: rickhanlonii
Differential Revision: D18828704
fbshipit-source-id: 931254c4328b93b946a7995e7d9d44cb5aeb6a7b
Summary:
In Paper this call causes Yoga to remeasure the tree. We don't need to do this in Fabric, and all the data contained in `ReactTextInputLocalData` is already set on the underlying EditText View.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18870491
fbshipit-source-id: a982a708b810d45f70ad4981a963bb4ae798c83c
Summary:
There are some code in native modules which currently throws exception when the host activity is not a FragmentActivity, even if the native module is not used. This change avoids the throw and fail the promise instead.
## Changelog
There are some code in native modules which currently throws exception when the host activity is not a FragmentActivity, even if the native module is not used. This change avoids the throw and fail the promise instead.
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/27425
Test Plan: We've tested the change on MS Office applications, which currently don't use FragmentActivity.
Differential Revision: D18873012
Pulled By: mdvacca
fbshipit-source-id: 1b7c9efba5a59b2051487510da9ef7e1232877a5
Summary:
We are seeing some non-trivial amount of crashes happened because `[RCTSurfacePresenter synchronouslyUpdateViewOnUIThread:props:]` requests a Component Descriptor which does not register in the registry.
And the problem here is that ComponentDescriptors are not being designed to be used outside of C++ UIManager, and we only use that in RCTSurfacePresenter only because it's an old workaround that makes Native Animation Driver works with Fabric.
Messing with ComponentDescriptors are in general dangerous. Accessing them outside of UIManager means that they might be deallocated at any time, extending their lifetime will cause other crashes on the other side. So, that's why this is "BROKEN".
This diff does not make the code worse, it just designates the problem that was there for a long time, so it kinda makes it better.
We don't know for sure why some ComponentDescriptors are not registered but this diff at least makes it not crash in such case.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18869651
fbshipit-source-id: 9d945ac7a2bd24a69a9bbb83b4fdd3cd19808f87
Summary:
Returning null from a NativeModule method that has a return type of `java.lang.Double` causes the program to crash. This diff instead makes that method call return `null` to JS. TurboModules already has this behaviour.
Changelog:
[Android][Fixed] - Support nullable returns NativeModule methods returning Boxed Primitives
Reviewed By: PeteTheHeat
Differential Revision: D18866872
fbshipit-source-id: 6049c4df6908f1d276c5674b7e06eb5e002a7976
Summary:
Changelog: [Internal] Remove groupCollapsed from list of unsupported polyfills
`console.groupCollapsed` was always replaced with `originalConsole`'s implementation, but
the right behavior is to have it be a proxy (call both `console` and `originalConsole`).
So remove this key from a list of unsupported functions.
Reviewed By: yungsters
Differential Revision: D18820158
fbshipit-source-id: d83cffbc7e7939c2654fad2e0d681da7c3b5196a
Summary:
It closes https://github.com/facebook/react-native/issues/24855
In the endRefreshProgrammatically of RCTRefreshControl.m there is calculation for content offset when spinner is shown CGPoint offset = {scrollView.contentOffset.x, scrollView.contentOffset.y - self.frame.size.height};
However self.frame.size.height is always 0 and therefore spinner is not visible
This change should fix that
Since the owner of the following PR is quite busy and won't be able to resolve the merge conflict anytime soon, I created this PR here to get the fix merged soon.
Ref: https://github.com/facebook/react-native/pull/27236
Thanks to [IgnorancePulls](https://github.com/IgnorancePulls)
## Changelog
[iOS] [Fixed] - Fix spinner visibility on beginRefreshingProgrammatically
Pull Request resolved: https://github.com/facebook/react-native/pull/27397
Test Plan:
IOS tests passed
Check whether this issue is reproduced or not for the repro which is described inside the issue.
https://github.com/facebook/react-native/issues/24855
Reviewed By: sammy-SC
Differential Revision: D18801307
Pulled By: hramos
fbshipit-source-id: d12af236778441a136dbe6b03dfd3495a465ae0f
Summary:
The integration of Flipper on iOS was crashing the template, and `test_ios_e2e` were failing because of it.
Flipper integration must be wrapped inside `FB_SONARKIT_ENABLED`.
Flipper's issues with Yoga and YogaKit were solved in Flipper 0.28.0, so let's update our integration to it, and we'll need to use Swift.
We will be able to ship this in 0.62 (cc grabbou, axe-fb, priteshrnandgaonkar), and it should fix `test_ios_e2e` (cc hramos) � .
## Changelog
[iOS] [Fixed] - Fix Flipper integration on and update Flipper to 0.30.0
Pull Request resolved: https://github.com/facebook/react-native/pull/27426
Test Plan:
- Initialized an app with my branch as source.
- Added `[AppDelegate initializeFlipper:application];` to `didFinishLaunchingWithOptions`.
- Launched Flipper.
- Ran the app (debug).
- Ran the app (release).
- Everything succeeds, no Flipper connection available in release.
Reviewed By: hramos
Differential Revision: D18841468
Pulled By: axe-fb
fbshipit-source-id: 73bb4810d1fbb6a96102848f8700ebb7c23a615b
Summary:
Special thanks for Joshua Gross for flagging this problem!
This diff implements a custom evicting hash map designed specially to hold text measurement information. The key feature of this is custom equality checks and hashing functions.
They are designed around the following principals:
* Decorative text attributes (such as color, shadows, etc) has no effect on layout, therefore they should not be taking into account;
* `minimum height`, `minimum width`, and `maximum height` don't affect the measurement;
* the value of `layout metrics` are important only for `attachment` fragments.
After I redo all tests, I will enable this for Android-specific TextLayoutManager in separate diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848583
fbshipit-source-id: 46c2fc445fbd1823afc5e7498e37de75381258b1
Summary:
In the previous diff, we noted that the maximum height is not really important for text measurement. That diff make is in code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848585
fbshipit-source-id: 5fe0ea8f76487a50baa8a2e024663a85afcd9861
Summary:
Here the deal with the clamp thing:
A layout engine asks nodes to measure their content providing layout constraints (min and max size) and that would be kind from nodes to return a result that in space of those constraints. Sometimes, satisfying that is an additional separate step of that operation, e.g. if we know that the intrinsic size of some node is `{100, 100}`, we need to clamp that to satisfy constraint `[min: {200, 200}, max: {inf, inf}]`.
In case when we need to cache measure information, it becomes tricky enough when we need to make the cache work most efficiently. For the case of measuring Text, we have an insight: the available maximum width is important, the rest three metrics (maximum height and minimum size) are not.
That means that any changes in those three metrics don't affect the actual measurement result but will affect the final value because the actual value will be clamped by constraints that didn't influence measuring in the first place.
That's why moving clamping outside of a cache is the first step into making it more efficient.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848584
fbshipit-source-id: 8feeb3f1a9d0e9691abac8be43639487a626fec3
Summary:
This diff allows re-connecting to the debugger websocket after reloading so that if, for example, metro has restarted, we'll reconnect to allow for debugging. Previously you would need to kill the app and re-open it to re-register the debugger websocket.
Changelog: [iOS] [Fixed] Reconnect to debugger websocket after metro is restarted.
Reviewed By: motiz88
Differential Revision: D18820399
fbshipit-source-id: ddbfa4476e70a6313c877a050ef2d77c04d1657e
Summary:
## Context
`NativeModuleRegistryBuilder` calls `TurboReactPackage.getNativeModuleIterator()` to access ModuleHolders for all the NativeModules in the `TurboReactPackage`. We then filter out the ModuleHolders that contain `TurboModules`, before using that list to make create the `NativeModuleRegistry`.
## Problem
Creating `ModuleHolders` has the side-effect of actually creating the NativeModule if it requires eager initialization. See [ModuleHolder.java](https://fburl.com/diffusion/4avdtio0):
```
class ModuleHolder {
// ...
public ModuleHolder(ReactModuleInfo moduleInfo, Provider<? extends NativeModule> provider) {
mName = moduleInfo.name();
mProvider = provider;
mReactModuleInfo = moduleInfo;
if (moduleInfo.needsEagerInit()) {
mModule = create(); // HERE!
}
}
```
So, we need to filter out TurboModules before we even create ModuleHolders.
Changelog:
[Android][Fixed] - Refactor TurboModule filtering in NativeModuleRegistryBuilder
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18814010
fbshipit-source-id: a120d2b619b9280ba70e21d131dccc5a9fc6346d
Summary:
These definitions make these libraries act as flow strict. We have them internally but need them in react native to be able to make files in react native flow strict.
Internally our flowconfig includes all the configs in react-native-github.
Changelog:
[Internal]: Add flow strict type definitions for modules
Reviewed By: zackargyle
Differential Revision: D18839594
fbshipit-source-id: d523e15f00a9cfa66d3789bb249655bcbe6d04eb
Summary:
By depending on react-native, these files can't be flow strict until index.js is flow strict. By depending on the internals directly they can be flow strict as soon as their dependents are flow strict.
Changelog:
[Internal] Refactoring some core file imports to depend on internals directly
Reviewed By: zackargyle
Differential Revision: D18828324
fbshipit-source-id: 2a347c4e234a64edbb3e6f0ef6387ef1ce78badc
Summary:
The TurboModuleManagerDelegate now supports a `getEagerInitModuleNames()` method, which is supposed to return a `java.util.List` containing the names of all NativeModules that require eager initialization. The NativeModuels are created when the `TurboModuleManager` is created. This happens inside `ReactInstanceManager.createReactContext` slightly after the NativeModuleRegistry is created, which is when our legacy NativeModules are eagerly initialized.
All NativeModules declared in `TurboReactPackages` that are wired into the `TurboModules` infra via `ReactPackageTurboModuleManagerDelegate` can use the `ReactModule(needsEagerInit = true)` annotation. Our build pipeline should correctly process the annotation into a `ModuleInfo`, and `ReactPackageTurboModuleManagerDelegate` should correctly forward the eagerly initialized module names to TurboModuleManager.
Changelog:
[Android][Added] - Implement TurboModule eager initialization support
Reviewed By: mdvacca
Differential Revision: D18819552
fbshipit-source-id: b2009a3b8f4e064362d2abeb5281637962531678
Summary:
Before this change, C++ couldn't propagate changes that updated TextInputs that were completely empty. In C++ the AttributedString cannot contain Fragments with empty text, so a completely empty TextInput would have no Fragments; this breaks the C++ state value updating infra since it relies on copying over existing fragments.
Instead, now we propagate default TextAttributes and ShadowView through State, so that State updates can use them to construct new Fragments.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D18835048
fbshipit-source-id: 58ac94c5454c8610c6287b096b62199045e5879b
Summary:
Support for modifying AndroidTextInputs with multiple Fragments was added on the Java side in a previous diff.
This diff adds support on the C++ side for the following scenario:
A <TextInput> is initially given contents via children <Text> notes, which represents multiple Fragments (that could have different TextAttributes like color, font size, backgroundcolor, etc). The Android EditText view must get this initial data, and then all updates after that on the Android side must flow to C++ so that the C++ ShadowNode can perform layout and measurement with up-to-date data.
At the same time, the <TextInput> node could be updated from the JS side. All else equal, this would cause the native Android EditText to be replaced with the old, original contents of the <TextInput> that may not have been updated at all from the JS side.
To mitigate this, we keep track of two AttributedStrings with Fragments on the C++ side: the AttributedString representing the values coming from <TextInput> children, from JS (`treeAttributedString`); and the AttributedString representing the current value the user is interacting with (`attributedString`). If the children from JS don't change, we don't update Android/Java with that AttributedString. If the children from JS do change, we overwrite any user input with the tree from JS.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D18785976
fbshipit-source-id: a1f3a935e02379cabca8ab62a39cb3c0cf3fbca5
Summary:
When the TextInput is updated on the Java side, make sure C++ State gets updated. We do this by making sure that the AttributedString data-structured in mirrored in Java and in C++.
In practice, the AttributedString is copied into Java a few times during initialization, and then after then, 99% of the time Java is writing without receiving updates from C++. This means that we should optimize the Java-to-C++ update path most aggressively in the future.
However, it turns out that for now, at least, we can't reuse NativeWritableMaps/NativeWritableArrays because they're consumed on the C++ side and can't be modified after that. This is a perf improvement for the future.
This allows us the user to edit any fragments, and the changes will flow through C++ State. This also allows us to edit across multiple Fragments.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18785960
fbshipit-source-id: 97b283ec411081eca4d2d7a4cce2b31b5e237c42
Summary:
For future diffs, we need to check AttributedStrings for equality.
It turns out that any time props or state change, two `parentShadowView`s will never be equal to each other, even if we'd consider them equal for our use-cases here for AttributedStrings. Just compare the tags instead of the whole object.
NOTE: I don't have any strong opinions about how we should be comparing them. It just isn't working currently for AndroidTextInput. Comparing tags seems convenient and reasonably correct for now.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18786004
fbshipit-source-id: 13c0e881cd8d2c2a207e8891309b3c9b880b827f
Kevin Gozali
David Vacca
Rick Hanlon
Ramanpreet Nara
Samuel Susla
Eli White
Valentin Shergin
Joshua Gross
Jordan Brown
Anandraj Govindan
Riley Dulin
Binh Nguyen
Nicolas Charpentier
