Summary:
Updates the paragraph component to use State instead of Local Data, part of the path to a Fabric TextInput 💯
## Changelog
[General] [Changed] - Fabric: Use State instead of Local Data for Paragraph
Pull Request resolved: https://github.com/facebook/react-native/pull/24873
Differential Revision: D15410979
Pulled By: shergin
fbshipit-source-id: 3c9517d2495a64c4dbd213b6efb5ff55287900e3
Summary:
In case `RCTView` had no subviews, `RCTRecursiveAccessibilityLabel` was returning an empty string rather than nil.
I've noticed that https://fburl.com/i95iynxi returns empty string as well. Shall we change it there as well?
Reviewed By: shergin
Differential Revision: D15337865
fbshipit-source-id: 8e38a88321f3dcfdf35a38d43fdbe4f5118796f1
Summary:
This is a reconstitution of #24190. It extends accessibility actions to include both a name and user facing label. These extensions support both standard and custom actions.
We've also added actions support on Android, and added examples to RNTester showing how both standard and custom accessibility actions are used.
## Changelog
[general] [changed] - Enhanced accessibility actions support
Pull Request resolved: https://github.com/facebook/react-native/pull/24695
Differential Revision: D15391408
Pulled By: cpojer
fbshipit-source-id: 5ed48004d46d9887da53baea7fdcd0e7e15c5739
Summary:
Straightforward.
Rick, I rename some stuff, I hope you are cool with that.
Reviewed By: mdvacca
Differential Revision: D15403306
fbshipit-source-id: 1dbd34060052a9bd39ed4211010f14b76fffcde6
Summary: This is implementation of standard PullToRefresh component that uses standard iOS component and modern integration approach.
Reviewed By: mdvacca
Differential Revision: D15403308
fbshipit-source-id: 5c877f7c18af9f5ac40e15a4ba44118614ba80bc
Summary: This way we can reuse this code in other RCTScrollViewComponentView-satellite components, especially in standard pull-to-refresh component.
Reviewed By: mdvacca
Differential Revision: D15403307
fbshipit-source-id: 5999f851f22db0f358887e1a86d610e163adcb1d
Summary:
Fix Issue https://github.com/facebook/react-native/issues/24820
It's caused by `_labelsForTags` and `RCTPLTag` being out of sync, the crash might only be one of the issues that this bug was causing.
## Changelog
[iOS] [Fixed] - fix crash on performance logger
Pull Request resolved: https://github.com/facebook/react-native/pull/24821
Differential Revision: D15407291
Pulled By: PeteTheHeat
fbshipit-source-id: c8d2a047fceb9cec981c48fe5181d1b4cbf0976c
Summary:
This diff contains two changes:
* The actual UIScrollView is now mounted inside the component as `contentView` which mostly means that border-props will properly affect the layout of the scroll view (the scroll view will be laid out inside borders, not on top of those). And that also simplifies the code.
* Now the component view exposes the actual scroll view, its delegate splitter, and the container view defining a single interface for all possible integration that can be done with the Scroll View Component.
Reviewed By: mdvacca
Differential Revision: D15397283
fbshipit-source-id: 35e860b8bf55fbd4d0a5f4116f79e4507df79098
Summary:
There was a reason why it exists: on iOS if you want to implement a view with rounded corners with a non-transparent background you need to set `clipToBounds = YES` to enabling clipping because besides drawing borders we need to clip the background otherwise it will "stick out".
There were a bunch of problems with this implementation and approach:
* It's overshooting. It applies `clipToBounds` no matter which border-radius is and no matter is there a background or not. So, it's kinda heuristic implementation and it's totally unexpected behavior sometimes.
* The previous problems can lead to performance problems as well (clipping requires additional work to do for CoreGraphics/GPU).
* The border-radius that we assigned to contentView is incorrect because it does not take border-width into account.
* This functionality only applies to non-null `contentView` which is a rear and custom case in which that can always be done manually for components that require that for some reason.
Reviewed By: mdvacca
Differential Revision: D15397282
fbshipit-source-id: 1599882ca8e591a9c4edb4d2b845bbf3d147bfce
Summary:
## Overview
This diff switches the RCTSlider onSlidingComplete event on iOS from a bubbling event to a direct (non-bubbling) event to match the non-bubbling type on android.
Note that in this case these seems like a bug. I will still explain the motivation and reasoning as this will come up in future diffs.
## Changelog
[Slider][BREAKING] Switch Slider onSlidingComplete event to a non-bubbling event on iOS to match Android
## Motivation:
The motivation here is that when we codgen the view configs, we'll need to unify all of the events and props across platforms for components that have the same name on iOS and Android.
In this case, the view configs (below) conflict for onSlidingComplete. On iOS this is under bubblingEventTypes, on Android this is under directEventTypes. We have code [here](https://fburl.com/3s1dahm2) in the react native renderer which ensures an event is not listed as both.
```
// iOS
const SliderViewConfig = {
bubblingEventTypes: {
onSlidingComplete: {
phasedRegistrationNames: {
captured: 'onChangeCapture',
bubbled: 'onChange'
}
}
},
directEventTypes: {
// None
},
validAttributes: {
// ...
}
};
```
```
// Android
const SliderViewConfig = {
bubblingEventTypes: {
// None
},
directEventTypes: {
onSlidingComplete: {
registrationName: 'onEventDirect'
}
},
validAttributes: {
// ...
}
};
```
## Solutions
There are three solutions to this issue:
1. Don't generate view configs
2. Rename the component on one platform
3. Make a breaking change in the event behavior on one platform to make it consistent across both platforms
Here we've chosen option #3
Reviewed By: TheSavior
Differential Revision: D15322304
fbshipit-source-id: ff1ab86efe9e2bc50fd3f7619e6760ab5c1c5090
Summary:
Some ObjC NativeModules conform to `RCTInvalidating` protocol and implements `invalidate` method. This is typically used to clean things up during bridge teardown or reload. In TurboModule system the invalidate method can be replaced by pure destructors, but for backward compatibility, we call existing invalidate method on each module during teardown.
This also cleans up all existing LongLivedObject's.
Reviewed By: mdvacca, RSNara
Differential Revision: D15365655
fbshipit-source-id: 802844b39b5b7adb54970ea541f4d744bbf9e480
Summary:
With the introduction of TurboModules, it would be beneficial to measure the setup time of these modules, as we currently have it in place for NativeModules.
The instantiation of the TMs occurs in the `RCTTurboModuleManager`. In order to successfully measure the time it took to setup the module, we need to ensure that we don't take into account cached modules. As such, we need to:
1. Check if module is in `_turboModuleCache`
a. Start mark for `RCTPLTurboModuleSetup` tag if not found
2. Get the TM via `[self provideTurboModule:]`
3. Check if module is in `_turboModuleCache`
a. Stop mark for `RCTPLTurboModuleSetup` if we did not find module in cache prior to **step 2** and if it's now present in the cache.
b. Notify about setup time if the above is true.
4. Return TM
## Changelog
[iOS] [Added] - Gain insights on the the turbo module setup times by observing `RCTDidSetupModuleNotification`. The userInfo dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/24732
Differential Revision: D15362088
Pulled By: RSNara
fbshipit-source-id: e6a8044e4aba5a12ae63e9c7dbf707a17ec00180
Summary: Future improvements in RCTScrollViewComponentView require ability to have multiple listeners of UIScrollViewDelegate (e.g. PullToRefresh component needs it), therefore we need a splitter to support it.
Reviewed By: JoshuaGross
Differential Revision: D15345301
fbshipit-source-id: 62bb50c4fdd4fa64ece5d7cc6ddc76367c84c4b3
Summary:
This is the final piece of change that makes measuring (`LayoutableShadowNode::getRelativeLayoutMetrics()`) take ScrollView content offset into account (on iOS).
It works pretty simply: at the end of scrolling (or zooming) action ScrollView updates the state which later can be used for computing `transform` which measuring uses to adjust values in LaoutMetrics.
Reviewed By: mdvacca
Differential Revision: D15323688
fbshipit-source-id: fdf86c6cd9bdfd56caddd4b39bdd1185760b9f94
Summary: Seems we need this now to enable future improvements in ScrollView such as correct measure, pull-to-refresh and so on.
Reviewed By: mdvacca
Differential Revision: D15323687
fbshipit-source-id: fae37431ccbbf2faec9c84752396153689b873ef
Summary: We don't need it anymore because we don't use folly::Future.
Reviewed By: JoshuaGross
Differential Revision: D15344961
fbshipit-source-id: a368e600d69e6879f6a98b4a997de85c71186e92
Summary:
The bug description can see https://github.com/facebook/react-native/issues/24688, we add `contentView` size check before center the content, because in some cases, the contentView's size not yet be calculated, in those cases, we don't adjust the `contentOffset`.
cc. cpojer .
[iOS] [Fixed] - Fixes ScrollView centerContent not work in some cases
Pull Request resolved: https://github.com/facebook/react-native/pull/24817
Differential Revision: D15322502
Pulled By: sahrens
fbshipit-source-id: e2081f13e9f2e8597a379a9db1607451ea496909
Summary: `YogaStylableProps.yogaStyle` is designed to be consumed by Yoga only. Making it `protected` allows us to avoid confusion and misuse of this props.
Reviewed By: JoshuaGross
Differential Revision: D15296474
fbshipit-source-id: cf9e416afee99fb426d72765557b34d303a63dbe
Summary: We needed that in the very beginning when diffing algorithm produces mount instructions for <Text> nodes which don't have ComponentView representation, so we simply silence those error here. That's not the case anymore, so we don't need those ugly checks.
Reviewed By: JoshuaGross
Differential Revision: D15296473
fbshipit-source-id: ea3717062056907e5395776fe95e3d581d3e9b09
Summary: RCTComponentViewRegistry is not a thread-safe class and must be accessed only from the main thread.
Reviewed By: JoshuaGross
Differential Revision: D15296475
fbshipit-source-id: 67192abd6290191f3b8119972efc41cec48a793a
Summary: Now it's implementled differently (see -[RCTComponentViewRegistry preallocateViewComponents]), so this code is not being used.
Reviewed By: mdvacca
Differential Revision: D15242045
fbshipit-source-id: c02eceb978cf1eae778f84a73456e7156ccf503b
Summary:
ImageLoader is an actual external dependency, not a ImageManager.
That change allows to remove dependency on ImageManager from SurfacePresenter and make some other code simpler.
Reviewed By: mdvacca
Differential Revision: D15242047
fbshipit-source-id: 8622d15b8fdb5c3a7e25091adf7be1108f87ecd5
Summary: The particular meaningful piece of code that diff removes was added as (successful) attempt to fix an issue which was lately fixed by D14868547.
Reviewed By: mdvacca
Differential Revision: D15242046
fbshipit-source-id: 88a3e3c629d7c5f84c402b03e45034644147fec4
Summary: RCTBridge does not need to retain RCTSurfacePresenter, so we enforce that using `OBJC_ASSOCIATION_ASSIGN`.
Reviewed By: mdvacca
Differential Revision: D15273325
fbshipit-source-id: f223192ff5f781d9e905b004907739a36882bb63
Summary:
Fixes an issue introduced in https://github.com/facebook/react-native/pull/15894 that can cause events to be dispatched out of order.
Also reverted `viewTag` moved to optional property as it didn't actually work and makes code more complex.
[iOS] [Fixed] - Fix event ordering when combining coalescable and non-coalescable events
Pull Request resolved: https://github.com/facebook/react-native/pull/24693
Differential Revision: D15279513
Pulled By: shergin
fbshipit-source-id: 3c64aba6d644ea9564572e6de8330b59b51cf4a9
Summary:
React Native Gesture Handler uses a `RCTViewManager` subclass to manage `UIControl` so the cast to set accessibility props is not safe. This moves the accessibility props we set to `UIView+React` so they can be used safely on any `UIView`.
![image](https://user-images.githubusercontent.com/2677334/57042641-46e42700-6c33-11e9-9a97-76661ad5d14d.png)
[General] [Fixed] - Move accessibility props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/24743
Differential Revision: D15258062
Pulled By: cpojer
fbshipit-source-id: 4a25b79407e5cb7b3b368c7506161e989794bb26
Summary: I have noticed that `backfaceVisibility` example crashes (because actual value is a string/enum, not a boolean), so I fixed it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219261
fbshipit-source-id: 27f76cd10903794d597adacb9da7300a42813f8e
Summary: Apparently we can/should not have in RCTConversions because it creates unnecessary dependency to core iOS module.
Reviewed By: mdvacca
Differential Revision: D15055325
fbshipit-source-id: 507f5a40c03b5c261967de4504297d31ecd02783
Summary:
When trying to load image using method "RCTImageFromLocalAssetURL", if URL's path in file system representation return null (in my case, imageUrl is base64 format returned from server so it's always null) then method "stringWithUTF8String" will raise an exception.
[iOS] [Fixed] - Fix exception when attempt to load image from file system
Pull Request resolved: https://github.com/facebook/react-native/pull/24457
Differential Revision: D15123680
Pulled By: shergin
fbshipit-source-id: bc34b3d7c79a8f9157729c4cf0486507c3c15ddf
Summary:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary: For some reason the scroll events are sometimes generated with highly irregular spacing, some coming less than a millisecond apart. For interactions that must track scrolling exactly, this can cause them to glitch. With a scroll throttle of less than 17 ms, the intention is clear that the UI should be updated in sync with the scroll view so we shouldn't drop any events.
Reviewed By: PeteTheHeat
Differential Revision: D15068841
fbshipit-source-id: 730e7cb29cc3ddae66f37cf7392e02e0cc9d7844
Summary:
@public
RCTScrollView sometimes asserts with another contentView set. While this doesn't crash, it'd be good to know what's causing the assert. This will add a recursive description of the contentView.
Changelog: [iOS] [Changed] RCTScrollView: added debugging to help fix assert
Reviewed By: PeteTheHeat
Differential Revision: D15049869
fbshipit-source-id: 5431de7764881922327c6c0a3bdd392668396b58
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
UAs must adjust border radius values to fit a content box:
>>> Corner curves must not overlap: When the sum of any two adjacent border radii exceeds the size of the border box, UAs must proportionally reduce the used values of all border radii until none of them overlap.
This diff implements that.
Reviewed By: mdvacca
Differential Revision: D15028325
fbshipit-source-id: 368232ffa2fa0409d13759bbbe7fe10f8474c400
Summary:
ShadowTree commits happen concurrently with limited synchronization that only ensures the correctness of the commit from ShadowTree perspective.
At the same time artifacts of the commit () needs to be delivered (also concurrently) to the proper thread and executed in order (not-concurrently). To achieve this we need some synchronization mechanism on the receiving (mounting) side. This class implements this process.
Practically, this diff fixes a problem with glitching UI during the very first render of Fabric screen.
Reviewed By: JoshuaGross
Differential Revision: D15021794
fbshipit-source-id: 62982425300c515e92b91e1e660b45455a5446e9
Summary:
`MountingTransaction` encapsulates all artifacts of `ShadowTree` commit, particularly list of mutations and meta-data.
We will rely on this heavily in the coming diffs.
Reviewed By: JoshuaGross
Differential Revision: D15021795
fbshipit-source-id: 811da7afd7b929a34a81aa66566193d46bbc34f8
Summary:
Registries, providers, providers of registries, registres of providers. All that can be really confusing, but that represents best the constraints and desires that we have:
* We need to be able to register components on-the-fly (so we need a mechanism that will propagate changes);
* We don't want to register ComponentDescriptors separately from ComponentView classes;
* C++ not always gives us abstractions that we want (e.g. pointers to constructors).
After the change, we can remove the whole Buck target that has a bunch of handwritten boilerplate code.
There is a still room for polish and removing some concepts, types or classes but this diff is already huge.
Reviewed By: JoshuaGross
Differential Revision: D14983906
fbshipit-source-id: ce536ebea0c905059c7a4d644dc25233e2809761
Summary:
ComponentDescriptorProvider represents unified way to create a particular descriptor.
Now all ComponentViews (which support RCTComponentViewProtocol) expose a `ComponentDescriptorProvider` which will allow creating and registering ComponentDescriptor instances for all visual components automatically as a part of ComponentView registration process.
Don't panic, everything is still being as explicit as it always was, no magic involved; we just will have only one registration step instead of two parallel.
That also opens a way to register components on the fly.
Reviewed By: JoshuaGross
Differential Revision: D14963488
fbshipit-source-id: 9e9d9166fabaf7b30b35b8647faa6e3a19cd2435
Summary: If some class or category override/implement one of those methods, it implies that subclasses must call super for them. `NS_REQUIRES_SUPER` allows to enforce this constraint.
Reviewed By: JoshuaGross
Differential Revision: D14896804
fbshipit-source-id: a481f16e1f7ab901d70deb6486f2ca1cf19dd8d7
Summary:
Previously we could call `invalidateLayer` twice during a mounting transaction (one for update-props, one for update-layout-metrics), that was sub-optimal.
Now, with `finalizeUpdates:` we can do it only once. That should save us some CPU cycles.
Reviewed By: JoshuaGross
Differential Revision: D14896802
fbshipit-source-id: b6572fb2a4fa48a12b1d1c29144cd7c67f6cff80
Summary: We use this pattern already and seems we use it more. Those two functions introduce a "semantical" wrappers for this context, so now there is no need to think which exact `__bridge ***` qualifier we should use, so it's much less error-prone.
Reviewed By: JoshuaGross
Differential Revision: D14896800
fbshipit-source-id: 85b86bfcefdad5aff0375e7172769df86c001506
Summary:
The new method is being called right after all update methods were called for a particular component view.
It is useful for performing updates that require knowledge of several independent aspects of the compound mounting change (e.g. props *and* layout constraints).
Reviewed By: JoshuaGross
Differential Revision: D14896801
fbshipit-source-id: 485d8c97d81d7a2ad7a7afc209094c328da6ef3c
Summary:
Would like feedback from the community as this may not be the best solution for all
I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.
This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.
To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature #21302 .
[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045
Differential Revision: D14939754
Pulled By: sahrens
fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
Summary: This is to prepare for custom JS runtime binding installation. Note: AppDelegate needs to become .mm
Reviewed By: cpojer
Differential Revision: D14932538
fbshipit-source-id: 30f32223cc405d0cace9e3076b5a2a1d8cc9e3b2
Summary:
Closes: https://github.com/facebook/react-native/issues/24016
React Native 0.57 introduced cross-platform `accessibilityRole` and `accessibilityStates` props in order to replace `accessibilityComponentType` (for android) and `accessibilityTraits` (for iOS). With #24095 `accessibilityRole` and `accessibilityStates` will increase, receiving more options, which seems to be a good moment to remove deprecated props.
Remove deprecated `accessibilityComponentType` and `accessibilityTraits` props.
[General] [Removed] - Remove accessibilityComponentType and accessibilityTraits props
Pull Request resolved: https://github.com/facebook/react-native/pull/24344
Reviewed By: rickhanlonii
Differential Revision: D14842214
Pulled By: cpojer
fbshipit-source-id: 279945e503d8a23bfee7a49d42f5db490c5f6069
Summary:
There are cases where native modules will try to reference other native modules during startup, which can causes a deadlock on `RCTModuleData::_instanceLock`.
My system was in a state where the deadlock would repro 100% so I could actually debug it a bit, but really this whole system is very fragile and needs to die in a fire.
I tried a recursive lock and it was not sufficient - there are definitely issues with multiple threads invoking at the same time and then calling `RCTUnsafeExecuteOnMainQueueSync`...
Reviewed By: fkgozali
Differential Revision: D14863583
fbshipit-source-id: 8c0d062353595a4ed3871aa9135950bc57983907
Summary:
This diff replaces all MountItem classes with a bunch of static C functions that do the same job as classes did.
Seems, originally we overestimated the complexity of MountItem classes and that they ended up being notably trivial. Now, maintaining that even longer would mean paying for abstractions and allocations that we don't really need and writing a lot of tedious code.
Besides that, the one particular change that will be introduced in the coming diffs is not particularly fit very well in the existing class-based model.
This change also should save us many hundreds of allocations and atomic counters bumps, so maybe we can get a millisecond-or-two win.
This diff does not introduce any practical behavioral/logical changes in the mounting layer.
Reviewed By: mdvacca
Differential Revision: D14893764
fbshipit-source-id: 6f1247923ae36f29c12a7d358e2d496cf6c3e298
Summary: The changes made in D14811733 introduced a regression in React Native's open source iOS tests.
Reviewed By: fkgozali
Differential Revision: D14895096
fbshipit-source-id: 4307b094e3bc94e9f703b0271a95a9b318bcd49a
Summary:
Currently, `RCTLocalAssetImageLoader` only support directory of `Library` and `App bundle`, actually, we need to support other directories like `tmp` or `Documents`. Otherwise, the local image load in `tmp` or `Documents` would be handled by `NSURLSession`, we don't need that.
<img width="405" alt="image" src="https://user-images.githubusercontent.com/5061845/54188126-0ba66100-44ea-11e9-9a7b-0f721100e9be.png">
[iOS] [Fixed] - Enhance search of directories when load local asset image
Pull Request resolved: https://github.com/facebook/react-native/pull/23857
Differential Revision: D14894136
Pulled By: shergin
fbshipit-source-id: 26361cd952a423467be9af9a84a80100d868776b
Summary:
This allows an unsupported component to be rendered as a "unimplemented view" for better visualization of which component is missing. It is off by default, but configurable in the component factory.
For now, the layout simply follows regular <View />, which means the width/height etc is based on the react component styling. The side effect is that components with 0 height/width won't show up at all.
Reviewed By: mdvacca
Differential Revision: D14869656
fbshipit-source-id: f31e012fb7dc1c64fcc431ea5aa45079a23a618e
Summary:
In the case where the first rootView we load enables Fabric, the UIManagerBinding ended up calling AppRegistry (JS) too early, before the bridge was fully ready. This means AppRegistry wasn't set up yet, causing redbox.
To fix this, RuntimeExecutor impl should ask the bridge to queue the callback instead of asking the MessageQueueThread directly. MessageQueueThread only works well IFF the bridge is alive, but it has no knowledge about whether the bridge is alive or not. To support this, we add `invokeAsync` impl to the RCTCxxBridge.
Reviewed By: JoshuaGross
Differential Revision: D14868547
fbshipit-source-id: 3b3f2b9150e930b4a2c71012242305241fc6dbed
Summary:
The root cause comes down to the fact that historically `-DFOO=0` and `-DFOO=1` patterns have been used when it comes to preprocessor definitions and various engineers use `#ifdef FOO` and `#if FOO` interchangeably. That results in an incorrect pattern because the real evaluation is following:
- `FOO` not defined: `#if FOO` = `FALSE`, `#ifdef FOO` = `FALSE`.
- `-DFOO=0`: `#if FOO` = `FALSE`, `#ifdef FOO` = `TRUE`.
- `-DFOO=1`: `#if FOO` = `TRUE`, `#ifdef FOO` = `TRUE`.
Reviewed By: aditya7fb
Differential Revision: D14811733
fbshipit-source-id: a7fedc56ab0ce8eedcb48bda783739a4c1eecf81
Summary: This will simplify updating the JSI API from upstream in the future.
Reviewed By: mhorowitz
Differential Revision: D14762674
fbshipit-source-id: fa4a86f08425943e301da4ef3df9893ebaa1493e
Summary:
Main change is to the property diffing - we now use the last known props set on the view rather than the default props to compute the diff. This requires exposing a `getProps` method on all view components which should be fine I think.
I also realized that in more complex animations with multiple nodes, the node that the animation starts on might not be connected to a view, so we don't know if it's fabric just based on that, so we have to do a recursive search through the children to find if there are any that are associated with a fabric view to decide we should start the animation immediately. Unfortunately there can still be a timing gap here since the animated API is async and the uimanager API is sync - I'll need to change the animated API to be sync to completely fix this.
Reviewed By: shergin
Differential Revision: D14732028
fbshipit-source-id: 882c056b0b63aa576f8e42439be405cf7fb3147a
Summary: This moves the iOS WebView files to be fb internal which completes the removal of WebView from React Native open source as part of the Lean Core effort.
Reviewed By: TheSavior
Differential Revision: D14630076
fbshipit-source-id: 7bc11d6c1470bb748c823c86cbb8b5ee94b508ff
Summary:
ScrollView's scrollTo behavior on iOS was recently changed to limit the offset to the content size plus any content inset (see #23427). This departure from the old behavior created UI issues for anyone that is using the over-scroll ability for the purpose of positioning elements at specific coordinates on the screen. Examples include using this behavior to position TextInputs above the virtual keyboard programmatically when focused or moving drop down elements positioned near the bottom of the content toward the top of the screen when selected to show a larger absolutely positioned item list. Default behavior does not change and this is an "opt-in" type of prop to re-enable the old behavior.
[iOS] [Added] - Added scrollToOverflowEnabled prop to ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/24296
Differential Revision: D14762619
Pulled By: cpojer
fbshipit-source-id: d2a552b5cb321d52e8ea4116327bf9ec647a3aae
Summary:
There is a timing issue when reloading the bridge (in dev mode) and the tear down of the TurboModules. This causes `Instance` to never get freed, hence the "bridge" isn't cleaning up properly. The side effect can be bogus error saying that it's unable to find a module.
To address this, JSCallInvoker should just take in weak_ptr<Instance>.
Reviewed By: RSNara
Differential Revision: D14739181
fbshipit-source-id: f9f2a55486debaeb28d3d293df3cf1d3f6b9a031
Summary: A retain-cycle regression was added by D14162776 and detected here: T41208740. Fix should be trivial.
Reviewed By: shergin
Differential Revision: D14709784
fbshipit-source-id: bad6ab31a5170e9320c4432cbd20d02ec6164f38
Summary:
It closes#24170.
I opened the issue yesterday, and I think I found the way how to resolve it. So, I'm opening this PR directly without any comment on the issue.
In the `endRefreshProgrammatically` of `RCTRefreshControl.m`, the comment says that " The contentOffset of the scrollview MUST be greater than 0". However, if the `contentInset` prop is set for the `FlatList`, I think `contentOffset` can be a negative value after refreshing and should be greater than `-contentInset.top`.
As I reported the bug in that issue, If I am using `contentInset` prop to the `FlatList`, making `contentOffset` value be always 0 when refreshing ends causes something wrong situation.
[iOS] [Fixed] - Fix setting the contnetOffset when refreshing ends
Pull Request resolved: https://github.com/facebook/react-native/pull/24191
Differential Revision: D14710987
Pulled By: sahrens
fbshipit-source-id: 03f06df9a93a2a46a7cc0b56269091778805917e
Summary:
Xcode 10.2 forbids creating categories for swift class that uses `+load` method. In react-native categories like this are used to register swift classes as modules (macro `RCT_EXTERN_MODULE`) This PR changes it to use `__attribute__((constructor))` instead of objc `+load` method.
I introduced new macro for this purpose, `RCT_EXPORT_MODULE_NO_LOAD`, it expands in something like:
```
void RCTRegisterModule(Class);
+ (NSString *)moduleName {
return @"jsNameFoo";
}
__attribute__((constructor)) static void initialize_ObjcClassFoo{
RCTRegisterModule([ObjcClassFoo class]);
}
```
Functions marked with `__attribute__((constructor))` are run before main and after all `+load` methods, so it seems like correct thing to do.
Fixes https://github.com/facebook/react-native/issues/24139
Doc about loading order https://developer.apple.com/documentation/objectivec/nsobject/1418815-load?language=objc
[iOS] [Fixed] - Fix runtime crash in xcode 10.2 when using RCT_EXTERN_MODULE for swift classes.
Pull Request resolved: https://github.com/facebook/react-native/pull/24155
Reviewed By: javache
Differential Revision: D14668235
Pulled By: shergin
fbshipit-source-id: 0c19e69ce2a68327387809773848d4ecd36d7461
Summary:
Otherwise reloading from metro deadlocks like this:
`[RCTSurfaceRegistry _stopAllSurfaces]` is calling `[RCTSurfaceRegistry enumerateWithBlock]` which locks `_mutex` and then we call `surfaceForRootTag` which then deadlocks on the same mutex:
https://pxl.cl/tmm1
Reviewed By: shergin
Differential Revision: D14679843
fbshipit-source-id: 9f4ecdfa7a79fcf7f3fc2ce437d4399b00910f26
Summary:
If size is zero, the `CGContext` would invalid, so we need to filter zero things.
cc. shergin
[iOS] [Fixed] - Fix invalid CGContext when invalidate layer
Pull Request resolved: https://github.com/facebook/react-native/pull/24195
Differential Revision: D14683396
Pulled By: shergin
fbshipit-source-id: b5b45fb86ca3158284281460cf1d95d1b22eab0d
Summary: When calling into JS (e.g. promise resolve/reject, callback) in TurboModule, we bypass the bridge's message queue. At times this causes race condition, where there are a bunch of pending UI operations (in RCTUImanager) waiting to be flushed, but nothing adds calls to the message queue. Usually tapping the screen will trigger the flush because we're sending down touch events to JS.
Reviewed By: JoshuaGross
Differential Revision: D14656466
fbshipit-source-id: cb3a174e97542bf80f0a37b4170b6a8e6780fa35
Summary:
This makes the RCTEvent protocol more generic to make it easier to use the event coalescing feature for type of events other than components. This does a few other improvements that will be useful in follow up PRs.
- Add `RCTComponentEvent` which is used instead of deprecated `[sendInputEventWithName:body:]` and remove that method completely (was only used at 2 places).
- Make `coalescingKey` optional for events that return NO from `canCoalesce`.
- Make `viewTag` optional for events that are not related to views.
- Fast path for events that return NO from `canCoalesce`.
- Add a missing test for event coalescing with different view tags.
Ended up making only one PR for all this since the changes are related and hard to separate.
**Migration**
Use a custom RCTEvent subclass with `[sendEvent:]` (preferred way to allow type safe events) or `RCTComponentEvent`.
**Test plan**
- Ran RCTEventDispatcher unit tests
- Tested manually in RNTester
Changelog:
[iOS] [Changed] - Remove deprecated RCTEvent method, sendInputEventWithName:body:
Pull Request resolved: https://github.com/facebook/react-native/pull/15894
Reviewed By: shergin
Differential Revision: D13726194
Pulled By: hramos
fbshipit-source-id: 11f63a99e08f46ec6b4f16f8d9949cdbf5c3fe13
Summary:
This PR is a follow-up to #21211 by request of hramos to incorporate some additional crash fixes / synchronization edge cases found in our production testing. What follows is largely a copy of the original PR description from #21211 - see that PR for original discussion thread as well as context on why this replacement PR was needed.
This PR is a minimalistic change to RCTTiming that causes it to switch exclusively to NSTimer (i.e., the 'sleep timer') in order to continue triggering timers when the app has moved to the background.
Many people have expressed a desire for background timer support on iOS. (See #1282, #167, and #16493). In our app — a podcast/audio player — we use background timers to ensure that we never lose track of the user's playback position, should the app crash or be terminated by the OS.
The RCTTimer module uses a RN-managed CADisplayLink if the next requested timer is less than a second away; otherwise, it switches to an NSTimer (which is refers to as a 'sleep timer' in source). The RN-managed CADisplayLink is always disabled when the app goes to the background (and thus cannot be used); however, the NSTimer will still issue its callbacks in the background.
This PR adds a flag to track whether the app is in the background, and if so, all timers are routed through NSTimer until the app returns to the foreground. vishnevskiy at Discord opened a similar PR (#16493) that implements a drop-in for CADisplayLink which falls back to NSTimer, but I decided to incorporate the background-NSTimer logic directly into RCTTimer, since NSTimer is already in use.
It's worth noting that the background NSTimer may not fire as often as requested — it may give the appearance of lagging depending upon your app's priority in the background. For our audio app, NSTimer fires exactly on schedule if there's an open AVAudioSession and audio is playing; if audio is not playing, it fires about half as often as requested, which is still adequate for networking polling and other tasks.
It's worth noting that background timers only function as long as an app is actually running in the background. Apple offers a variety of Background Modes (which can be toggled in the Capabilities section of the target inspector in Xcode), and the app will need to be legitimately using one of these modes in order for this change to provide any value — otherwise it will be terminated within a couple of seconds of moving to the background.
The good thing about this change is that for apps that do perform essential computation in support of their Background Mode, they can now use `setTimeout` and `setInterval` without problem — whereas in the past, neither would ever trigger their callback until the app returns to the foreground.
Pull Request resolved: https://github.com/facebook/react-native/pull/23674
Differential Revision: D14621326
Pulled By: shergin
fbshipit-source-id: c76e060ad2c662c140d7d2f4fb5aaa7094032515
Summary:
We will use it inside `core` module, so we have to decouple it from `view`.
As part of this, I added some comments, changed `const Float &` to just `Float` and put the implementation into `.cpp` file.
Reviewed By: mdvacca
Differential Revision: D14593952
fbshipit-source-id: 80f7746f4fc5b95febc8df9f5a9c0386a6425c88
Summary: This is based on the work done in D8686586. Removed the logger instance from JSIExecutor constructor and installed it into the runtimeInstaller at all call sites.
Reviewed By: mhorowitz
Differential Revision: D14444120
fbshipit-source-id: 0476fda4230c467573ea04102a12101bcdf36c53
Summary:
With our current infra, we support automatic conversion of method arguments using `RCTConvert`.
```
RCT_EXPORT_METHOD(foo:(RCTSound*) sound)
{
//...
}
```
```
interface RCTConvert (RCTSound)
+ (RCTSound *) RCTSound: (NSDictionary *) dict;
end
implementation RCTConvert (RCTSound)
+ (RCTSound *) RCTSound: (NSDictionary *) dict
{
//...
}
end
```
```
export interface Spec extends TurboModule {
+foo: (dict: Object) => void,
}
```
With this setup, when we call the foo method on the TurboModule in JS, we'd first convert `dict` from a JS Object to an `NSDictionary`. Then, because the `foo` method has an argument of type`RCTSound*`, and because `RCTConvert` has a method called `RCTSound`, before we invoke the `foo` NativeModule native method, we first convert the `NSDictionary` to `RCTSound` using `[RCTConvert RCTSound:obj]`. Essentially, if an argument type of a TurboModule method is neither a primitive type nor a struct (i.e: is an identifier), and it corresponds to a selector on `RCTConvert`, we call `[RCTConvert argumentType:obj]` to convert `obj` to the type `argumentType` before passing in `obj` as an argument to the NativeModule method call.
**Note:** I originally planned on using `NSMethodSignature` to get the argument types. Unfortunately, while the Objective C Runtime lets us know that the type is an identifier, it doesn't inform us which identifier it is. In other words, at runtime, we can't determine whether identifier represents `RCTSound *` or some other Objective C class. I figure this also the reason why the old code relies on the `RCT_EXPORT_METHOD` macros to implement this very same feature: https://git.io/fjJsC. It uses `NSMethodSignature` to switch on the argument type, and then uses the `RCTMethodInfo` struct to parse the argument type name, from which it constructs the RCTConvert selector.
One caveat of the current solution is that it won't work work unless we decorate our TurboModule methods with `RCT_EXPORT_METHOD`.
Reviewed By: fkgozali
Differential Revision: D14582661
fbshipit-source-id: 3c7dfb2059f031dba7495f12cbdf406b14f0b5b4
Summary:
The `RCTBridge` contains numerous definitions of notification names, which we can observe in order to get insights into the React Native performance.
The Android implementation is a little different, such that you can listen for any of the [following](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/bridge/ReactMarkerConstants.java) marker constants, simply by including the following code:
```java
ReactMarker.addListener(new ReactMarker.MarkerListener() {
Override
public void logMarker(ReactMarkerConstants name, Nullable String tag, int instanceKey) {
Log.d("ReactNativeEvent", "name: "+ name.name() + " tag: " + tag);
}
});
```
This will allow you to perform the necessary processing, calculations as required.
---
This PR enables observing for the module setup event (`RCTDidSetupModuleNotification`) by including the respective module's name & setup time in milliseconds.
[iOS] [Added] - Gain insights on the module setup times by observing `RCTDidSetupModuleNotification`. The `userInfo` dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey ` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23859
Differential Revision: D14579066
Pulled By: PeteTheHeat
fbshipit-source-id: 52645127c3fc6aa5bd73e3bd471fccd79cb05c14
Summary:
Fix for this issue I rasied: https://github.com/facebook/react-native/issues/24024
When I toggle `Show Perf Monitor` and reload JS `CMD+R` the Perf Monitor will be hidden, but settings in dev menu will persist. So to fix this state and need to `Hide Perf Monitor` and `Show Perf Monitor` again to see it.
[iOS] [Fixed] - Show Perf Monitor, after reloading JS
Pull Request resolved: https://github.com/facebook/react-native/pull/24073
Differential Revision: D14560025
Pulled By: cpojer
fbshipit-source-id: cd5602bd6ee041b8b3e61d163d10bd8bc47237b9
Summary:
Change the function called when an error is returned from the completionHandler of the `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)`.
* AS-IS
- `RCTLogError()`
- This error method does not post any notification for users. So users cannot receive notification when `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)` complete with error.(i.e. bundleURL is is invalid but not nil, `http://1`, `http://localho:8081/index.bundle`)
* TO-BE
- `handleError(error:)`
- Call this method will post notification for users when `completionHandler` fails with error.
[iOS] [Fixed] - Change the function called when an error is returned from the completionHandler of the `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23837
Differential Revision: D14538790
Pulled By: cpojer
fbshipit-source-id: da3306904c0d8113d204edfaa0f9e2a23793981a
Summary:
Put `prepareForRecycle` to last before enqueue to recycle pool, ensure only call it when count lower than RCTComponentViewRegistryRecyclePoolMaxSize.
cc. shergin .
[General] [Changed] - Reorder prepareForRecycle before adding recycle pool
Pull Request resolved: https://github.com/facebook/react-native/pull/24025
Differential Revision: D14536843
Pulled By: shergin
fbshipit-source-id: 82a816e2c0afb5a6bb72637d7d55d6a4fda708af
Summary:
We need to remove adding png file extension when path has not extension. Two reasons:
1. `imageWithContentsOfFile` or other `UIKit` methods can load png image correctly, even if path has not `png` file extension.
2. Sometimes, people may have file that actually not have file extension, it's the designated behavior for user. Like #23844 .
CC. sahrens cpojer .
[iOS] [Fixed] - Remove explicitly add png file extension when load local image
Pull Request resolved: https://github.com/facebook/react-native/pull/23864
Reviewed By: shergin
Differential Revision: D14425373
Pulled By: hramos
fbshipit-source-id: 3cc06c9a3d68cadf652c1de742f3cce26258c874
Summary:
I encountered invalid bridge error when I develop (reload high frequency) some times, and if it happened, I only can restart the app, because we would always show error invalid message if we trigger reload command. So I recommend Change invalid bridge log level from error to warn, I think it's enough.
cc. cpojer .
<img width="375" alt="892C97F4-E910-4E3B-935A-65C899916E6E" src="https://user-images.githubusercontent.com/5061845/54538344-0d32c600-49cf-11e9-818c-0e4cb5a0a518.png">
[iOS] [Fixed] - Change invalid bridge log level from error to warn
Pull Request resolved: https://github.com/facebook/react-native/pull/24005
Differential Revision: D14504820
Pulled By: cpojer
fbshipit-source-id: f24c4876fdb3e64183c09c5ddc598a8c87e405a7
Summary:
This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera.
The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks.
- Yarn Install
- Uncomment the commented out pods in RNTester's pod file
- Open RNTesterPods workspace
- Run App
- this is only for pods, the non-pod RNTester will no longer work until updated with fabric too.
- `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is:
1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called.
2. Add observer for `RCTJavaScriptDidLoadNotification`
3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`.
[General] [Added] - Use Fabric in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23803
Reviewed By: shergin, mdvacca
Differential Revision: D14450726
Pulled By: fkgozali
fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
Summary: Several things need to ironed out: 1) LocalState in Fabric C++, 2) setting dimensions of BottomSheet component to 0,0 for parent.
Reviewed By: shergin
Differential Revision: D14426167
fbshipit-source-id: 45a90a7971c87672872108a9e360926b4a6095f0
Summary:
From https://github.com/facebook/react-native/pull/23861#issue-260337314
> changing "interval" example from "time-only" to "datetime" because there's a known bug that prevented the previous example from working
We need to ensure set minuteInterval after set datePickerMode, otherwise minuteInterval invalid in time mode.
cc. grabbou cpojer .
[iOS] [Fixed] - Fixed minuteInterval invalid in time mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23923
Differential Revision: D14477549
Pulled By: cpojer
fbshipit-source-id: 2c612d488b6d592b1907e150df5e07fe83132829
Summary:
As a follow-up to this other PR #23839, it adds support for other, iOS only, flags into `AccessibilityInfo`.
It adds these other 4 methods:
* `isBoldTextEnabled()`
* `isGrayscaleEnabled()`
* `isInvertColorsEnabled()`
* `isReduceTransparencyEnabled()`
P.S: Android implementation for those methods just return `false` (with `Promise.resolve(false)`)
And the corresponding event listeners:
* `boldTextChanged`
* `grayscaleChanged`,
* `invertColorsChanged`,
* `reduceTransparencyChanged`
Pull Request resolved: https://github.com/facebook/react-native/pull/23913
Differential Revision: D14482214
Pulled By: cpojer
fbshipit-source-id: b97725fd12706957d4dad880a97e6b0993738272
Summary:
D14323747 broke SSTs. This PR optimized implementation of nativeID. Instead of searching entire tree to find a view, it uses a map to cache views which have nativeID set. The map uses keys with format <nativeID-rootViewTag>. Finding the rootViewTag causes a race condition, due to [this syncing code](https://fburl.com/93vqzlbg). The SST runner attempts to read the map to find a [SST view](https://fburl.com/8zadz024) before that view is added to the map.
My fix is to change the key format to simply <nativeID>. Product code should not duplicate nativeID since it is used to uniquely identify react managed views from native. I'll comment on PR with this fix.
Reviewed By: shergin, mmmulani
Differential Revision: D14416262
fbshipit-source-id: 3b707f2ff4049ac83ac8861e3cda435224d973d8
Summary:
Part of: #23313.
This moves the `RCTTest` lib from `Libraries/RCTTest` to `RNTester/RCTTest`. This also removes `takeSnapshot` from React Native, and implements it as a standalone module in RNTester called `ScreenshotManager`.
[General] [Removed] - RCTTest & ReactNative.takeSnapshot
Pull Request resolved: https://github.com/facebook/react-native/pull/23721
Differential Revision: D14434796
Pulled By: PeteTheHeat
fbshipit-source-id: d6e103a0ea0b6702701cdb5ce8449163ca4628ce
Summary:
We need to add SurfacePresenterStub header to project header for tvOS.
Related 544d9fb10b
CC. sahrens .
[iOS] [Fixed] - Add SurfacePresenterStub header to project header for tvOS
Pull Request resolved: https://github.com/facebook/react-native/pull/23855
Differential Revision: D14436185
Pulled By: cpojer
fbshipit-source-id: b59369541e78967346fc9e9fa6a9685725834f39
Summary:
This fixes a few memory leaks in fabrics handling of colors for borders, when using CGColorRef's we must be diligent about releasing the memory back.
[iOS] [Fixed] - Border style memory leaks
Pull Request resolved: https://github.com/facebook/react-native/pull/23815
Differential Revision: D14431250
Pulled By: shergin
fbshipit-source-id: dc663c633ae24809cb4841800d31a6ac6eeb8aa5
Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot.
But native crashes were (and still are) much harder to diagnose.
..Until now :D
I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help.
The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr).
I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly.
I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling.
After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it.
In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`.
The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym.
I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code.
Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost!
Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice.
I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above.
[iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them.
[General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/23691
Reviewed By: fkgozali
Differential Revision: D14276366
Pulled By: cpojer
fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
Summary:
This change fixes https://github.com/facebook/react-native/issues/23645.
The issue is that the `YGMarker.cpp`, `YGValue.cpp`, `YGConfig.cpp` and `log.cpp` files are already included in the Yoga compilation unit, so including these files in React's compile sources too results in "duplicate symbols" errors when loading React Native with `-force_load` (which behaves slightly differently to `-ObjC` - according to a colleague, "ObjC will scan through each object file in each library and force linking of any object file that contains Objective C code, while force_load will link every object file in a particular staticlib (regardless of whether or not the object file contains Objective C code)").
These changes seemed to be introduced by a few commits:
- D13819111 -> 43601f1a17
- D13439602 -> b5c66a3fbe
- D14123390-> e8f95dc7a1
- D7530369 -> 95f625e151
Perhaps we need to check with the original authors/any C++ experts to confirm if this fix is correct - it compiles for me but I'm not sure what the original intention of these changes was.
[iOS] [Fixed] - Remove duplicated Yoga compile sources to prevent "duplicate symbols" errors when linking using -force_load
Pull Request resolved: https://github.com/facebook/react-native/pull/23823
Reviewed By: davidaurelio
Differential Revision: D14387657
Pulled By: hramos
fbshipit-source-id: d85221b6dc1a0377662624f4201b27222aed8219
Summary:
I measured the performance of UIMananger methods and found that `create` method spends a significant amount of time on preallocating views (around 10 ms on my device). Interestingly, this time was actually spent on dispatching operations on the main thread, not on performing those operations. That makes me think about think about the preallocation problem one more time.
(Here and later I discuss preemptive optimistic preallocation views on iOS, but the issues are more-less applicable for all platforms.)
BTW, what's view preallocation? – In React Native we believe that we can get significant TTI wins instantiating platform views ahead of time while JavaScript thread is busy doing reconciliation and the main one is idle.
So, seems the current approach has those downsides:
* We spend too much time on dispatching only (jumping threads, creation Objective-C blocks, managing them in GCD, incrementing atomic refcountes inside `ShadowView` and so on). That's wasteful.
* We don't have much information during preallocations that can help prepare something to save time in the future. We don't know the future size of the component, so we cannot e.g. pre-draw a border or even allocate memory for a future drawing.
* We pre-allocate to much. At the moment of component creation, we don't know will this component be filtered out by view-flattening infra or not, so we always allocate a view for it. That's ~30% more views that we actually need.
* We don't stop allocating (or dispatching instructions for that) after the recycle pool is already filled in. That's also wasteful.
Why is this so bad and how can we fix it properly?..
I thought about this problem for months. And I think the answer is trivial: We don't know the exact shape of the interface until we finish creating it, and there is no way to overcome this problem on the client side. In the ideal world, the server size (or hardcoded manifest somewhere) tells the renderer (at the moment where we started navigating to it) how many views of which type will some surface use.
And until our world is not so perfect, I think we can get a significant performance improvement doing simple preallocation of 100 regular views, 30 text views, and 30 image views during rendering the first React Native surface. So I hardcoded that.
Reviewed By: JoshuaGross
Differential Revision: D14333606
fbshipit-source-id: 96beeb58b546258de1b8fd58550e0ae412b78aa9
Summary:
Right now we rely on the Paper UIManager to update animated node graphs - this hooks us into `RCTSurfacePresenter` in the same way so we are no longer reliant on Paper. Should also help with complex ordering corner cases with pre vs. post operations and restoring defaults when nodes are removed. More info:
https://github.com/facebook/react-native/pull/11819/files
Note that we don't have a way to differentiate animation nodes related to fabric views vs. paper views, so if paper and fabric are both rendering updates simultaneously it's possible they could get processed by the wrong callback. That should be very rare, rarely cause problems even if it does happen, and won't be a problem at all in a post-Paper world.
Reviewed By: shergin
Differential Revision: D14336760
fbshipit-source-id: 1c6a72fa67d5fedbaefb21cd4d7e5d75484f4fae
Summary:
We currently rely on the Paper UIManager calling `uiManagerWillPerformMounting` to flush the animated operations queue, which includes starting and stopping animations. This mostly works right now because Fabric always starts after Paper, but sometimes Paper doesn't fire `uiManagerWillPerformMounting` for a while, which can delay an animation starting.
To fix this, I force a flush of the queues on the UIThread whenever start or stop is called. This should be safe because the order of animation operations is still preserved, and start/stop are (almost?) always called in dedicated event handler loops, so any other updates like changing the way nodes are attached should already have been processed from a previous JS execution loop.
Reviewed By: JoshuaGross
Differential Revision: D14313502
fbshipit-source-id: 2a2b0c614fd1a591bd04b6b3fafcc09ff6c9d6e7
Summary: Use the codegen for the Slider component with the new `inferfaceOnly` option
Reviewed By: TheSavior
Differential Revision: D14295981
fbshipit-source-id: 0482572892fbcffada43c7c6fbf17e70546300b8
Summary:
Implement TODO, implement the nativeID functionality in a more efficient way instead of searching the whole view tree.
[iOS] [Fixed] - Implement the nativeID functionality in a more efficient way
Pull Request resolved: https://github.com/facebook/react-native/pull/23662
Differential Revision: D14323747
Pulled By: shergin
fbshipit-source-id: 3d45dbf53ad2b6adb79b4331600d53b51ede76d4
Summary:
Between invalidating a bridge and suspending its JS thread, native modules may have their methods called.
Only warn when a native module has been invalidated, which happens right before its JS thread is suspended.
Avoid initializing a native module's instance if its bridge is invalidated.
/cc fkgozali f945212447 (commitcomment-32467567)
[iOS] [Fixed] - Properly validate JS->native method calls
Pull Request resolved: https://github.com/facebook/react-native/pull/23658
Differential Revision: D14287594
Pulled By: fkgozali
fbshipit-source-id: 89dd1906a0c55f3f48ba4ff220aac0cddf2eb822
Summary:
We have parse code to try to support exported method parameter annotated `__unused` and `nullable`, but actually, seems we don't support it entirely, for example, we parse `__unused` firstly, then we parse `nullable`, actually, this case not exist, because `nullable` macro must appear right after `(`, before `__unused`, so we can't parse success, leads to error signature and crash.
[iOS] [Fixed] - Fixed method invoke when both nullable and __unused exist
Pull Request resolved: https://github.com/facebook/react-native/pull/23726
Differential Revision: D14298563
Pulled By: cpojer
fbshipit-source-id: 934e1d384a5d67b7bbf117fd2dec51f50979c979
Summary:
We need to check `body[@"target"]` wether equal to `nil`, if it is, return to prevent crash.
[iOS] [Fixed] - Fixed crash if event doesn't have body parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/23711
Differential Revision: D14298543
Pulled By: cpojer
fbshipit-source-id: d5e8cd69438f323ae102e61618c0371a01bee347
Summary:
For the `NullabilityPostfix`, we can use `_Nullable` or `__nullable`. Please see https://developer.apple.com/swift/blog/?id=25 , and we also use it in our code.
[iOS] [Added] - Added support of __nullable and __nonnull for module exported method signature
Pull Request resolved: https://github.com/facebook/react-native/pull/23731
Differential Revision: D14298483
Pulled By: cpojer
fbshipit-source-id: 4dd3188f51be3808ea2b97ce19aa7a85ea1f4a9e
Summary: This diff removes the "isLayoutable" parameter from SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation. This now can be infered from the shadowView parameter
Reviewed By: shergin
Differential Revision: D14296481
fbshipit-source-id: b200504f9c2bef41f0a70257f1f5a274fbe97cbb
Summary:
Update Props during pre-allocation avoiding re-updating the same props during mounting
MobileLab test showed an improvement of:
MARKETPLACE_YOU_TTI_SUCCESS: -3.34% = 58ms
Reviewed By: shergin
Differential Revision: D14252170
fbshipit-source-id: 1f4e9ad5dcecbc06651fa065135ffeed4892d984
Summary:
We are now generating the native cpp files for ActivityIndicatorView via Buck.
Deleting the hand written files and switching over.
Reviewed By: TheSavior
Differential Revision: D14247446
fbshipit-source-id: 63a6df3254e4184de6c8abb9ea2c89654ad54398
Summary: TurboModule needs sync calls from JS to native, and that's not supported with the current Chrome debugger. Until we have proper solution, disable it to avoid confusion.
Reviewed By: PeteTheHeat
Differential Revision: D14286383
fbshipit-source-id: e93903bf8fdfc714960d0d58e3f3eb0442c811bd
Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary:
This is a back-out of D14214844, we noticed that this regressed TTI for Marketplace You screen running in Fabric
Original commit changeset: b81005f2bf49
Reviewed By: JoshuaGross
Differential Revision: D14247897
fbshipit-source-id: de0cea92b437b2fbcd075f0d6a0066156800e3f0
Summary: The changes allows to get the State object on mounting layer and initiate the updates.
Reviewed By: mdvacca
Differential Revision: D14217185
fbshipit-source-id: 370644e06e350932e93c39adbe46544b071c28b3
Summary:
We already only support `iOS9+`, so we can remove all compatible codes now.
[iOS] [Fixed] - Remove compatible system code for iOS8 and before
Pull Request resolved: https://github.com/facebook/react-native/pull/23656
Differential Revision: D14224986
Pulled By: hramos
fbshipit-source-id: cac9ffe6788dd3eaf4f4f5f2b219f325ba78e85f
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
Reviewed By: shergin
Differential Revision: D14214844
fbshipit-source-id: b81005f2bf494f62f421dc24846e1561e13b9a87
Summary:
Not super clean, but not terrible.
Unfortunately this still relies on the old Paper UIManager calling delegate methods to flush the operations queues. This will work for Marketplace You since Paper will be active, but we need to fix this, along with Animated Events which don't work at all yet.
Random aside: it seems like taps are less responsive in fabric vs. paper, at least on iOS. There is a sporadic delay between the touches event coming in nativly to the JS callback invoking the native module function to start the animation - this will need some debugging.
Reviewed By: shergin
Differential Revision: D14143331
fbshipit-source-id: 63a17eaafa1217d77a532a2716d9f886a96fae59
Summary: [iOS] [Changed] - There seems to be a potential race condition during reloading that could cause "double registration" of modules. This should be mostly harmless, so downgrade to warning for the message instead of redboxing.
Reviewed By: cpojer
Differential Revision: D14179922
fbshipit-source-id: 5c16ac674f633a548353277d9f875544ed10ba9b
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](353d44f649/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.
The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.
*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)
[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559
Differential Revision: D14179326
Pulled By: cpojer
fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
Summary:
When an image source is parsed via `RCTImageFromLocalAssetURL` there seem to be certain situations in which `imageName` is empty from `RCTBundlePathForURL`. Any call to `UIImage imageNamed` with a an empty parameter will throw an exception:
```
CUICatalog: Invalid asset name supplied: '(null)'
```
In my case, the asset URL was pointing to an image in the application sandbox rather than the `NSBundle`. In this case `UIImage imageNamed` was throwing before the call to `NSData dataWithContentsOfURL` below could correctly resolve the image.
This change simply skips the call to `UIImage imageNamed` if no `imageName` value is set.
Pull Request resolved: https://github.com/facebook/react-native/pull/20120
Differential Revision: D14163101
Pulled By: cpojer
fbshipit-source-id: ceec95c02bf21b739962ef5618947a5726ba0473
Summary:
Add an option to dev menu to change packager location on the fly on iOS (similar to Dev Settings in Android)
Pull Request resolved: https://github.com/facebook/react-native/pull/21970
Differential Revision: D14162776
Pulled By: cpojer
fbshipit-source-id: 3cca4f4fbd8c599bd5342ba1ae64905a03270d48
Summary:
Fix scrollview `offset` out of content size in iOS, Android uses `scrollTo` and `smoothScrollTo` which not have this issue.
Fixes like #13594#22768#19970 .
[iOS] [Fixed] - Fixed scrollView offset out of content size.
Pull Request resolved: https://github.com/facebook/react-native/pull/23427
Differential Revision: D14162663
Pulled By: cpojer
fbshipit-source-id: a95371c8d703b6d5f604af0072f86c01c2018f4a
Summary:
Fixes#23500 , if user set prop `contentInsetAdjustmentBehavior="automatic"` of ScrollView, it not works when initial on the screen. We fixes it by filter valid offset, if offset is valid, just return.
[iOS] [Fixed] - Fixed ScrollView adjust inset behavior
Pull Request resolved: https://github.com/facebook/react-native/pull/23555
Differential Revision: D14161593
Pulled By: cpojer
fbshipit-source-id: 01434e55106ffde7f8e39f66dd5b0f02df9b38b1
Summary:
I downgrade the invalid bridge warning because I believe that it is a pain that every time that the JS gets refreshed this warnings are being thrown. If the project increase size and more and more NativeModules are added this warnings just spam the emulator or the device.
I understand the reason of validating if the bridge is valid. However in case of invalidness nothing is done, just the warning is thrown. Hence, the reason of downgrading it to improve the development process.
The error message still exist and it will be in the logs. But it will not spam the development screen
[iOS] [Changed] - Downgrade the Invalid bridge warning message to a log
Pull Request resolved: https://github.com/facebook/react-native/pull/23557
Differential Revision: D14161290
Pulled By: cpojer
fbshipit-source-id: e5608a9b2db5625309fd18d133fe69a9013043f3
Summary:
As part of #22609, this fixes yet more warnings.
- Adding more __unused to params.
- Refactors `isPackagerRunning` to use NSURLSession.
- Turns off suspicious comma warnings
[iOS] [Fixed] - Xcode Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23565
Differential Revision: D14161151
Pulled By: cpojer
fbshipit-source-id: 339874711eca718fc6151e84737ccc975225d736