Summary:
Original commit changeset: 4b18a931a2e4
The original PR wherein these changes were introduced was problematic. When you expose headers that use C++ from the Yoga podspec, they get automatically imported in the Yoga umbrella file. This causes compilation errors, most likely because it's possible for non-c++ files to import these headers (i.e: RCTConvert.m).
I didn't dig into this too much, but since Fabric still doesn't fully compile in OSS, I think it's reasonable to revert this PR for now. cc Kevin Gozali.
Changelog:
[iOS][Fixed] - Undo Fabric-related podspec change
Reviewed By: fkgozali
Differential Revision: D18284536
fbshipit-source-id: a90454b945af0235424dc56408400cd35efd4e7a
Summary:
Looking at the crash reports from T46487253:
1. This crash happens only with TurboModule-compatible NativeModules.
2. Users who experience this crash are in the TurboModules test group.
Therefore, the crash happens while trying to load TurboModules.
The stack trace of the crash includes [this lookup via the NativeModule system](https://fburl.com/diffusion/vxj9goz5). When TurboModules are enabled, we can only start executing this line if one of two things are true:
1. The TurboModuleRegistry is null in CatalystInstanceImpl.
2. The TurboModuleRegistry isn't null but the NativeModule returned by the TurboModuleRegistry is null.
We can protect against 1 by asserting that when `ReactFeatureFlags.useTurboModules` is `true`, `mTurboModuleRegistry` is not null. Once this check lands, unless there's a race with setting `ReactFeatureFlags.useTurboModules`, we should be able to rule out 1.
Changelog:
[Added][Android] - Assert TurboModuleRegistry isn't null before using it in CatalystInstanceImpl
Reviewed By: PeteTheHeat
Differential Revision: D18211935
fbshipit-source-id: de88c033425c474ef80b73386b7182b1d3bb382f
Summary:
This diff adds Fast Refresh support for dismissing LogBox syntax errors. We don't dismiss all errors because once a syntax error is fixed you'll still want to see the covered fatals, errors, and warnings.
If you actually full reload, then it falls back to the native redbox.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278889
fbshipit-source-id: f109ca1d6c34aa3eda6e434deca66f8ce5e02ce0
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
Summary:
In the next diff we'll introduce syntax errors, which we don't show stackframes for since they don't make sense. This diff removes the Stack Frame section when there are no stack frames available.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278831
fbshipit-source-id: 0a6ad5c3b7fed76123b6ad3ccfc8f3f0b044bda2
Summary:
This diff adds handling to fatal errors such as thrown exceptions by popping them full screen and not allowing the user to dismiss them. They say that they're "Fatal Errors" and explain that "Fatal errors require a reload".
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18257185
fbshipit-source-id: ca051027b19c3cd2410ae59764d7b98a78f08dca
Summary:
Quick diff to avoid the logging of Props, State and localData in Fabric Android.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18277486
fbshipit-source-id: 462335e7dadaab2bd39a8ede6318f52f95dfb53a
Summary:
In previous implementation, `setNativeProps` was called before `render`. These two methods can change value of `selectedIndex` and it matters in which order they arrive in native.
This was fine in Paper because 1st selectedIndex is set from `setNativeProps` with wrong value and then correct value comes from props.
However in Fabric, 1st selectedIndex comes from props (this is the correct one), and 2nd comes from command which has the incorrect value.
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D18240118
fbshipit-source-id: dca897306d3e858b9175b2f81356c76f5a0f79e2
Summary:
The `StatusBarManager` NativeModule does not have a uniform API on iOS and Android. In particular, the `setStyle` and the `setHidden` methods have an additional parameter on iOS:
```
/**
* - statusBarStyles can be:
* - 'default'
* - 'dark-content'
* - 'light-content'
*/
+setStyle: (statusBarStyle?: ?string, animated: boolean) => void;
/**
* - withAnimation can be: 'none' | 'fade' | 'slide'
*/
+setHidden: (hidden: boolean, withAnimation: string) => void;
```
If we keep the NativeModule spec the same between the two platforms, we'd have to keep the second parameter optional for both methods. This works for `setHidden`, because the second parameter is a string, and optional strings are allowed. However, for `setStyle`, the second parameter is a number, and we don't support optional numbers/booleans on Android in the NativeModule system. If we keep the optional number, then the following check triggers in our RedBox tests on iOS, which makes them fail: https://fburl.com/diffusion/b7adezd9.
So, since the two specs are sufficiently different, I figured that the easiest path forward is to split them apart.
Changelog:
[iOS][Changed] - Separated NativeStatusBarManager into NativeStatusBarManager{IOS,Android}
Reviewed By: PeteTheHeat
Differential Revision: D18214161
fbshipit-source-id: 6fd8b8c5f576244b5b90ee47faa7f50508c5e1d3
Summary:
Using compiler flag -fvisibility=hidden and explicitly setting visibility to default to public methods
#Changelog:
[Internal] [Yoga] Use compiler flag -fvisibility=hidden for reducing yoga binary size
Reviewed By: astreet
Differential Revision: D18029030
fbshipit-source-id: 545e73f9c25f3108fc9d9bb7f08c157dbc8da005
Summary:
We suspect that the re-registration of `ComponentDescriptorProvider`s during Bridge reloading might cause crashes in Fabric core. That happens because the re-registration process replaces already existing and being used ComponentDescriptors in the managed registries with the exact same new ones, which forces old ones to be deallocated and all pointers to them invalid. (On of the fundamental Fabric design decision is that `ShadowNode`s don't own/retain ComponentDescriptors.)
It seems was already indirectly addressed in application code on iOS but still fixing that in the core is valuable.
Android implementation does not use reactive component registration, so it was already fine.
As the follow-up diff, we plan to remove "removing" capabilities from ComponentDescriptorRegistry and ComponentDescriptorProviderRegistry to make it even more future-proof.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18273683
fbshipit-source-id: 7615627842855f078a3fdf3049f5511f59700972
Summary:
This diff finally uses all facilities from the previous diffs to build an implementation of `RCTMountingTransactionObserving` protocol which does *not* require using expensive Objective-C runtime features.
In the coming diffs, we will see how it can/should be used.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217101
fbshipit-source-id: 34f411dcb527dc81570c2f2833ce13b40e1450db
Summary:
See the comment in RCTMountingTransactionObserving first.
I think we have to add this to the iOS mounting layer to be able reasonably easy implement things like:
* MovableNavigationBar: seems, currently we don't handle the situation when the container was mounted first and the nested scroll view second.
* TTI component: It does not have access to telemetry.
The protocol is meant to replace `RCTSurfacePresenterObserver`.
Changelog: [Internal] Fabric-specific change.
Reviewed By: mdvacca
Differential Revision: D16270107
fbshipit-source-id: 2d4bdb7d0092cc214cc433fc633e41e58f6677df
Summary:
RCTComponentViewClassDescriptor is a pretty much the same as RCTComponentViewDescriptor but for *classes*. RCTComponentViewFactory uses a map of those data structures to create RCTComponentViewDescriptor instances (which reflects the same properties) efficiently.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217103
fbshipit-source-id: ab7ab6b0712048d0085b61a3604b284b1fb5a68b
Summary:
This diff introduces RCTComponentViewDescriptor - the container for a view and associated with this view properties which mounting infra uses for bookkeeping (and recycling) views.
The previous implementation used raw Objective-C pointers to `UIView`s to store and manipulate them. The new way has a bunch of advantages:
* It allows using high-performant C++ data collections for storing views and their properties (in future diffs).
* The new approach allows us to avoid hacks around NSMapTable (such as ` [_registry setObject:componentView forKey:(__bridge id)(void *)tag];`) that were needed because NSMapTable wasn't designed for our use-case.
* Dealing with `RCTComponentViewDescriptor` which stores a pointer to a view sometimes is actually more efficient than dealing with those pointers themselfs because we can deal with `const &` to a descriptor which does not require a ref-counter bump.
* A new approach is much more flexible, it allows us to store additional data alongside view instances which we will use in coming diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217102
fbshipit-source-id: 063e6c7df794a2e1fd690c194fb31ad6833eaba7
Summary:
In addition to already exiting method `componentViewByTag`, this diff adds a new one `findComponentViewWithTag` which does pretty much the same thing but returns `nil` in a case when it cannot find a view with a given tag. The first method now returns a non-nullable object, whereas the second (new) one return nullable.
We need this to explicitly designate call-sites that are resilient to such kind of errors, where such errors are expected because of still-existing consistency problems (because of some legacy implementation approaches).
At the same time, for the call-sites where a missing view situation is unrecoverable, we should throw early and stop paying for nullability overhead.
In the future diffs, we will change the internal implementation of the registry where the price for dealing with nullability will be actually meaningful.
This is the first diff on the road to an implementation of `RCTMountingTransactionObserving` protocol.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217099
fbshipit-source-id: dc50033ecadd43c43c5a65fed62649a1a7acf2b5
Summary:
This method has no any usages.
Changelog: [Internal] Fabric-specific, internal change.
Reviewed By: sammy-SC
Differential Revision: D18217100
fbshipit-source-id: 7aabd9e83413c2a1040bdd6c1510d6e4a4c6446a
Summary:
With tvOS (Apple TV) now residing in a separately maintained fork, this removes the residual props from React Native. This only includes the JavaScript changes. The Objective-C changes will come later.
Specifically, the following props have been removed:
- `isTVSelectable`
- `tvParallaxProperties`
- `tvParallaxShiftDistanceX`
- `tvParallaxShiftDistanceY`
- `tvParallaxTiltAngle`
- `tvParallaxMagnification`
Note that `hasTVPreferredFocus` is still being used by Android TV, so it remains.
Changelog:
[Removed] Apple TV View Props
Reviewed By: TheSavior
Differential Revision: D18266278
fbshipit-source-id: 9d1448bf2f434a74e6eb23c70d3a37971e406768
Summary:
Omitted 'own'.. from 2nd para 3rd line.
Added comma in 3rd line after 'developing tools' under the "Upgrading" topic.
bugfixes>> Bug fixes in 7th line under topic "How to contribute".
## Changelog
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/26879
Differential Revision: D18268598
Pulled By: cpojer
fbshipit-source-id: fa64854cd7fbf049524042effe7a5f4a1d0d6a04
Summary:
Exports these events in a canonical manner so that they can be used in future refactors.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18257693
fbshipit-source-id: aac40277df8a88224c8df29caa04ffc9a6db0a22
Summary:
Use padding instead of setting size of SafeAreaView, this should make it more consistent with Paper component.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D18225793
fbshipit-source-id: 08dccbdae0e4f7a7847501a06e17d4c26473462a
Summary:
Order of arguments for `RectangleEdges` was incorrect
changelog: [internal]
Reviewed By: shergin
Differential Revision: D18231825
fbshipit-source-id: 188d7af405ce801437ff67999a8f7dae77ae03c0
Summary:
Fixes a bug for old versions of JSC that do not support `for of` syntax
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D18265611
fbshipit-source-id: 4643b6e2571c57ddd982661d188c3449f17a151e
Summary:
I've been working on a new iOS experience with lots of text inputs and this has been driving me a bit nuts…
If you're in a scrollview with `keyboardShouldPersistTaps="handled"` and you tab through your text-inputs, you aren't able to tap outside of a given text-input to blur it (and dismiss the keyboard).
I wrote up a quick explanation and some repo steps here: https://snack.expo.io/BJBcKgrqB
The patch i came up with, after poking around for a little bit seems terrifying - so almost certainly not it. But if it's helpful at all - decided to just got ahead and submit it.
## Changelog
[iOS] [Fixed] - TextInput blur when tabbing in iOS simulator.
Pull Request resolved: https://github.com/facebook/react-native/pull/27038
Test Plan:
I tried to think of a way to test this in jest… but i didn't get very far sorry 😢
I did create a snack here so you can demo the issue: https://snack.expo.io/BJBcKgrqB
I also created two videos…
**Here's the text input not working when i try to blur it after tabbing in simulator**
**Here's it working after I applied this patch**
Thanks!
Differential Revision: D18262867
Pulled By: TheSavior
fbshipit-source-id: 4087f3a27a7e6a146f7f84d7c6e9e8e2b6adc75d
Summary:
easy diff to avoid the constant copy of a vector when calling the method Binding.createRemoveAndDeleteMultiMountItem. Since we are not modifing the vector inside the method createRemoveAndDeleteMultiMountItem it's not necessary to copy it.
Changelog: Improve performance in mounting of Fabric views
Reviewed By: JoshuaGross
Differential Revision: D18250376
fbshipit-source-id: c984214a8148bab521cec51d42ba54a4b73e3e67
Summary:
This diff check if warnings are ignored before calling through to the wrapped console.warn implementation below, thus preventing ignored logs from being sent to adb/metro/flipper and cleaning them up a bit.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18239936
fbshipit-source-id: 533beced3e66ad1a4d0810933862c63a0b88628c
Summary:
Will not show native redboxes when LogBox handles them
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18236608
fbshipit-source-id: 1c60c69419b1a823594caf650d67693d4ad2076b
Summary:
This diff adds support for thrown exceptions to redboxes, and hides the native redbox when we show an error in LogBox.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18212064
fbshipit-source-id: 92031d554968bcb079f81568673ae85697c8f5ad
Summary:
This diff switches the exception manager over to the reportException native module function on iOS and adds a new field `extraData.showRedbox` as a temporary hack to control hiding/showing native redboxes for LogBox.
Once LogBox is rolled out we'll remove this field, so we're hacking it into the available unused and untyped extraData bag, which will simplify gutting it in the future.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18212047
fbshipit-source-id: f14e31d90359b7d455a73c2368ce010c28364a5c
Summary:
Currently if you land of a surface with a lot of logs, we're basically blocked until they stop. This diff schedules the log parsing in LogBox to free up the app to do other things.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18203391
fbshipit-source-id: 35c5f03316a1106a3a48e7770d5bb59c62a3694f
Summary:
This diff adds optimistic loading for symbolicated stack traces by so that we (almost) never show a loading state for stack traces. Because of this, we also remove the "Stack Trace" status except when it is loading or failed. Also refactored the related components to hooks 🎣
Changelog: [Internal]
Reviewed By: mmmulani
Differential Revision: D18110403
fbshipit-source-id: a93b0a63e1c9490fea73ca6ec7c5707670bdea53
Summary:
This parameter used to be useful for a custom format hermes was developing,
but since Hermes now outputs the Chrome format it isn't useful.
Chrome actually disallows prettified JSON, and requires a special version that is faster to parse.
Therefore, `compact` was the only supported mode.
Changelog: [Internal] Remove compact parameter from `createSnapshotToFile`
Reviewed By: willholen
Differential Revision: D17726742
fbshipit-source-id: 6f39af9046dff2f3b4fba822312a9a89c939ed89
Summary:
Use `reactTag` instead of address of `UIView` to map events from paper components to Fabric.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D17954974
fbshipit-source-id: 0d8bf748e58f4cb6769e107bc7fd0e66b93d8f12
Summary:
Simplify logic in `RCTLegacyViewManagerInteropComponentView` by caching views that are mounted and unmounted and applying it in finalise.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D17954975
fbshipit-source-id: 11c8ec9e6eabb8a838a83f5fc2428912f4ec9523
Summary:
Text paddings in Fabric are managed by LayoutMetrics, the current implementation of Fabric is incorrectly using padding data from Text Props to set the padding in the view.
This diff refactors the update of Text in Fabric in order to avoid using padding prop data
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18211638
fbshipit-source-id: de05e7daa6185d854ce1b6580a1e44ae55d3176e
Summary:
This diff enables the codegen ViewConfig in production, which have been running in Dev mode for 4+ months withouth any issue
Changelog: [Internal]
Reviewed By: rickhanlonii, ejanzer
Differential Revision: D18218546
fbshipit-source-id: cc74a89db1b1f8d9770a0b7dacb2fbfa6fd3a2d7
Summary: Pulls the `0.56.3` release tag internally, by adding the same changes and upgrading react-native-github metro dependencies to `0.56.3`.
Reviewed By: motiz88
Differential Revision: D18114219
fbshipit-source-id: 0be58255eb8c79267e8ea30ab2e9e3d96a794b92
Summary:
We no longer need to gate by OS version since we want to allow in-app theming. This diff ensures that we are passing in the updated system context to retrieve the correct app theme.
Changelog:
[Android] Enable AppearanceModule for all OS versions
Reviewed By: mdvacca
Differential Revision: D18224915
fbshipit-source-id: 42d5db8497d8bead32c49e3e2a25d4ba779e2b33
Summary:
This diff changes how arbitrary-node-replacing (aka `RootShadowNode::clone`) algorithm works.
Original implementation worked this way: We specified a node that needs to be replaced and a new replacement node. Then the algorithm finds a node with *the same family* as given the to-be-replaced node and replaced that with a given replacement.
The problem with this approach is that we are replacing a node that we have very little info about (we only know that it shares the same family as specified one). At the same time, we build the replacement based on the exact node that we have. Then imagine the case in which the "target" node can progress/change between a moment where we get a reference to it and a moment where we are trying to clone the tree. In this case, we will replace a "progressed" node with a modified version of the obsolete node.
Practically speaking, it was possible that during a state update we were replacing a node that just got new children with a bit older version of that with old children but with a new state.
How to deal with it? This diff introduces a new interface for this method that allows separating the target node and the actual act of cloning the corresponding node. Instead of specifying actual replacement, we now specify a function that performs the cloning/transformation on-demand on the very exact node that was in the tree at the moment of cloning.
This change does not change/affect any ownership-related relationships between trees and/or nodes.
Ideally, probably, the interface should accept ShadowNodeFamily instance instead of a ShadowNode instance to make the behavior very clear but that requires a bunch of low-level changes that it out of the scope of this fix.
```
The old approach.
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ A(r0) │ │ A(r1) │ │ A(r2) │
│ │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
│ Let's update the │ Meanwhile the node B │
▼ state of this ▼ gets new children. ▼
┌─────────────────┐ node to s1. ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │ Created
│ B(r0, s0) │ ───────▶ │ B(r1, s0) │ ───────▶ │ B(r2, s1) │ from
│ │ │ │ │ │ B(r0).
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
┌──────┴──────┐ ┌─────────────┼─────────────┐ ┌──────┴──────┐
│ │ │ │ │ │ │ What just
▼ ▼ ▼ ▼ ▼ ▼ ▼ happe..?
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ C(r0) │ │ D(r0) │ │ C(r1) │ │ D(r1) │ │ X(r0) │ │ C(r0) │ │ D(r0) │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
The new approach.
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ A(r0) │ │ A(r1) │ │ A(r2) │
│ │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
│ Let's update the │ │
▼ state of this ▼ ▼
┌─────────────────┐ node to s1. ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │ Created
│ B(r0, s0) │ ───────▶ │ B(r1, s0) │ ───────▶ │ B(r2, s1) │ from
│ │ │ │ │ │ B(r1).
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
┌──────┴──────┐ ┌─────────────┼─────────────┐ ┌─────────────┼─────────────┐
│ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ C(r0) │ │ D(r0) │ │ C(r1) │ │ D(r1) │ │ X(r0) │ │ C(r1) │ │ D(r1) │ │ X(r0) │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
```
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18229704
fbshipit-source-id: face6d0e5c240224ce49e93e783cff3172b60529
Ramanpreet Nara
Rick Hanlon
David Vacca
Samuel Susla
Sidharth Guglani
Valentin Shergin
Tim Yung
Priyanshu2001
Jacob Thornton
Riley Dulin
Eli White
Essam Ewaisha
Elisa Lou
