Summary:
None of the code inside `ReactInternal` depended on the `RCTLinkingManager` NativeModule. So I extracted `RCTLinking` into its own BUCK target. This will make it easier to make `RCTLinkingManager` TurboModule-compatible.
## Codemod
Everywhere we required `ReactInternal`, we now also require `RCTLinking`:
```
> xbgr -f 'BUCK$' 'ReactInternal"' -l | xargs -I {} sed -i '' $'s|ReactInternal",|ReactInternal",\"fbsource//xplat/js:RCTLinking",|g' $HOME/{}
> xbgr -f 'BUCK$' 'ReactInternalApple"' -l | xargs -I {} sed -i '' $'s|ReactInternalApple",|ReactInternalApple",\"fbsource//xplat/js:RCTLinkingApple",|g' $HOME/{}
> arc f
```
Changelog:
[Internal] - Separate RCTLinking from ReactInternal
Reviewed By: fkgozali
Differential Revision: D18314747
fbshipit-source-id: d9b5f536a6e93a0aca8721801a2ee5d446e0d4a6
Summary:
The diff moves an invocation of `_synchronizeAllSettings` from the constructor to `setBridge`. The side-effects of `_synchronizeAllSettings` rely on a bridge not being nil, so we need to ensure that the bridge is assigned to the instance before calling `_synchronizeAllSettings`.
Before the fix, enabling JavaScript debugger caused a stale and opening many copies of a debugger in Chrome.
Changelog: [Internal] Fixed race and possible stale in RCTDevSettings
Reviewed By: RSNara
Differential Revision: D18379596
fbshipit-source-id: 9f64b9bc5426720948113de61bc9ccc8c39193b4
Summary:
Interop layer can now forward commands to paper components.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D18285766
fbshipit-source-id: 33fe071c3000569d52fedcbcdeccc354dfe277d9
Summary:
This implement new <UnimplementedView> (only for iOS for now) that relies on the new "reactive component registration" functionality.
The `UnimplementedView` component is the perfect example of that. It's simple and uniquely required some constraints that we want to implement: the same component class registered several times with different handles and names.
This change serves two needs:
1. Providing an example of how that functionality can be used in more complex cases.
2. That will allow removing some `UnimplementedView`-specific code from the core (and very hot pathes of the system) and make them `noexcept`. That will eventually allow removing some public APIs from RawValue (constructing from folly::dynamic) that currently impose some implementation details and probably prevent us from making it slightly faster. There are only two consumers of this API, this is one of them.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D17211913
fbshipit-source-id: df1a1ac1a36289ef79904d509d38ee8b3f5588fb
Summary:
This diff removes `ComponentDescriptorProviderRegistry::remove()` and two derivative interfaces.
First, we don't use that and there is no concrete idea why we would need to use that. Those were originally built only for symmetry with limited knowledge about what exactly we need.
Second, those methods are actually dangerous and probably must not be supported by design. Removing a ComponentDescriptorProvider destroys already registered `ComponentDescriptor`s, and at the same time we might have ShadowNodes referring to that (which will cause a crash), and there is no reasonable way to check for the existence of those nodes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18285497
fbshipit-source-id: b461e38b923c217a256e1155689311397a994feb
Summary:
Revert some changes from D18148890 as they broke loading of RN surfaces with following error
``Invariant Violation: Expected HMRClient.setup() call at startup`
Changelog: [internal]
Reviewed By: mmmulani
Differential Revision: D18324764
fbshipit-source-id: f1b4af630f8330444f70a4d93be2b53f6d8e31c2
Summary:
In next diff Coordinator will have get more responsibilities therefore it's better to separate the concerns to different class
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18304834
fbshipit-source-id: 168a68969ed9da5772895f2da87e5273dccbaf30
Summary:
Now we also collect mounting time inside MountingTelemetry.
We will use it soon.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18285826
fbshipit-source-id: 512fc62c210a111614b0defb0d76cbd6228fe89f
Summary:
This will allow us to catch cases where we use iOS 10-only APIs on iOS 9
Changelog: [Internal]
Reviewed By: TheSavior, mmmulani
Differential Revision: D18275225
fbshipit-source-id: dc9c515415208db40750be997173ce5bd6eb494f
Summary:
A very common pattern I've seen in RN codebase:
- (instancetype) init {
[[NSNotificationCenter defaultCenter] addObserver:self ...]
}
- (void) dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self ...]
}
From Apple:
https://developer.apple.com/documentation/foundation/nsnotificationcenter/1413994-removeobserver?language=objc
> If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
RN targets iOS9+
Changelog: [Internal][Cleanup] Remove unneeded NSNotification center removeObserver
Reviewed By: shergin
Differential Revision: D18264235
fbshipit-source-id: 684e5f5555cec96b055b13cd83daaeb393f4fac9
Summary:
I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure.
**Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`.
Changelog:
[iOS][Fixed] - Fix all RN Podspecs
Reviewed By: fkgozali
Differential Revision: D18284535
fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
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:
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:
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:
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:
This diff adds back RN reload reason, which was removed earlier in the stack. cc/Rick
For callsites which already had a reason, I kept the string exactly the same. For callsites which didn't have a reason, I made up something reasonable.
Changelog: [Internal][Fixed] Re-implemented bridge reload reason text.
Reviewed By: RSNara
Differential Revision: D18074478
fbshipit-source-id: 64a3cd7718674a7ba7228a80e34791ce9f153f9f
Summary:
`RCTBridgeWillReloadNotification` has one job: whenever bridge reloads - trigger a reload in `RCTSurfacePresenter`.
Diff 1/2 deprecated bridge reloading APIs, and replaced them with `RCTReloadCommand`. Use that in `RCTSurfacePresenter` instead .
Changelog: [iOS][Deprecate] Deprecate RCTBridgeWillReloadNotification
Reviewed By: shergin
Differential Revision: D17880926
fbshipit-source-id: 00adc4d56d11d40ab371d81bb17a05609c184769
Summary:
Motivation described in diff 1/N.
This diff replaces calls to `[bridge reload]` with calls to `RCTReloadCommand`. This shouldn't have any change in behaviour since RCTBridge listens to RCTReloadCommand and calls `[bridge reload]` [here](https://fburl.com/diffusion/kemzkrei).
It will allow us to customize who listens and reacts to RN lifecycle.
Changelog: [Internal][Changed] - Migrated [bridge reload] calls to RCTReloadCommand
Reviewed By: shergin
Differential Revision: D17880909
fbshipit-source-id: 80b26c6badd4b216656fed6dd04554e9877f4bb7
Summary:
Testing the waters with an idea for unifying RN lifecycle with/without bridge.
### Motivation/Background
RN bridge is being reloaded from [several different places](https://fburl.com/codesearch/ae3zeatt). When this happens, the bridge does a bunch of things:
1. Post `RCTBridgeWillReloadNotification` (RCTSurfacePresenter listens to this and reloads)
2. Invalidate batched bridge, which does:
a. invalidate display link
b. post `RCTBridgeWillInvalidateModules/RCTBridgeDidInvalidateModules` (TurboModuleManager listens to this and reloads modules)
c. clear js thread state
d. clear some local caches
3. Set up (reload bundle and batched bridge)
In a bridgeless world, there isn't one thing which owns all these peices of infra, and can reload them.
### Plan
Use `RCTReloadCommand` to handle reloads. This light class previously only handled CMD+R. The new workflow looks like this:
1. Anything which cares about reloads can register itself as a listener. (RCTBridge, RCTSurfacePresenter, TurboModuleManager...)
2. Anything that previously called `bridge reload` now calls `RCTTriggerReloadCommandListeners`.
3. Delete old notifications
### Alternate Plan
Use yet another NSNotification. I like `RCTReloadCommand` better.
### Unknowns
Looks like we log the reason for bridge reloading [here](https://fburl.com/diffusion/lc9jj8la), do we want to save this behaviour? Does anyone look at why bridge is being reloaded cc/Rick? If so, I can add back that functionality to `RCTReloadCommand`.
It should be possible to customize the order/priority of what gets reloaded first. There may be some racy behaviour that I haven't thought about yet.
Changelog: [iOS][Deprecated] Deprecate [bridge reload] API - prefer RCTReloadCommand
Reviewed By: shergin
Differential Revision: D17869635
fbshipit-source-id: 81f39eaa2c3ce08ea1bc6f2193684c2630d81a2d
Summary:
The private API isPackagerRunning is useful. Rather than duplicating it, I am exposing it here so that I can make use of it in future PRs, and so others can do the same.
## Changelog
[iOS] [Changed] - Expose the isPackagerRunning methods on RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/27012
Test Plan: This change doesn't impact any runtime code, though it does impact build. I used a vanilla test app (react-native init) and built it using xcode as well as react-native run-ios.
Differential Revision: D18174316
Pulled By: cpojer
fbshipit-source-id: 523d134882303f68a1f69521e31f29d7dbfb666c
Summary:
On iOS the promised returned by `Share.share(content, options)` isn't resolved if the user dismisses the dialog by either pressing "Cancel" or pressing outside the shared dialog. This PR fixes this issue.
This fixes https://github.com/facebook/react-native/issues/26809.
## Changelog
[iOS] [Fixed] - Fix promised returned by `Share.share(content, options)` not resolving if share dialog dismissed
Pull Request resolved: https://github.com/facebook/react-native/pull/26842
Test Plan:
1. on iOS, open a share dialog with:
```typescript
const onShare = async () => {
const result = await Share.share({ message: 'example message' });
}
```
2. Dismiss the opened share dialog and the returned promised should resolve.
Differential Revision: D18189755
Pulled By: cpojer
fbshipit-source-id: 1269932e9549026afefdaa8478ff7d33bbaeb86f
Summary:
Searching for the ancestor view while measuring a shadow view layout relative to the ancestor is limited to `30`. I couldn't find the reason nor commit where it was introduced (because I have no access to internal facebook commits).
I think we should keep looking for an ancestor view until the shadow view has the superview property.
## Changelog
[iOS] [Fixed] - Remove maximum searching depth while measuring layout.
Pull Request resolved: https://github.com/facebook/react-native/pull/26986
Test Plan:
- Tested if RNTester works as expected.
- Tested in app with a lot of nested flatlists where sometimes I was facing this redbox because of the max depth limit.
<img width="297" alt="Screenshot 2019-10-24 at 14 40 11" src="https://user-images.githubusercontent.com/16336501/67486474-6309d380-f66c-11e9-9eab-15e8fb8372a5.png">
Differential Revision: D18175568
Pulled By: shergin
fbshipit-source-id: cd59a18032d10bc6dd5707981e69813810f65b5a
Summary:
Previously, Fabric (RCTSurfacePresenter) was unaware of the bridge being valid or not. That caused the strange situations where the bridge might be already dead is still running.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18050888
fbshipit-source-id: 34e3ec4b6991034410a40c041cfdcca36be8d743
Summary:
This diff introduces a new broadcasting event for Bridge that communicates that the bridge is being invalidated. This notification can be used by interested parties as a signal to start tearing down all bridge-dependant processes.
The biggest difference between the new event and `RCTBridgeWillInvalidateModulesNotification` is that the latter is being called asynchronously on the JavaScript thread, whereas the new one is being called on whatever thread caused the Bridge invalidation (deallocation) *synchronously*. In most cases that happens on the main thread that allows destroying strictly-main-threaded infra (mostly UI) synchronously and avoids races.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18050889
fbshipit-source-id: 9364c820ea2b0358edf45f0e2b3e16a13d730a9c
Summary:
The purpose of RCTRuntimeExecutorFromBridge is to create/implement RuntimeExecutor using some JS queue implemented as part of the Bridge. This diff changes the implementation of this method, specifically:
Removing dispatching a sync block. This causes a deadlock with TM sometimes and should not be generally required.
The implementation does not retain the Bridge anymore.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D17960236
fbshipit-source-id: 0ddea561a6884f066e483d6b0f41ddd1621df73c
Summary:
Yes, this is a pretty big diff; because of the high interconnectedness of the things, I failed to split it apart.
This change does:
Introduces a new class RCTSurfacePresenterBridgeAdapter which decouples all Bridge-related functionality from RCTSurfacePresenter.
The new class allows "replacing" one instance of the bridge with another for a single RCTSurfacePresenter.
This change allows implementing unloading a bridge (e.g. during memory pressure warning) and suspending all RN surfaces with the future possibility of reloading a bridge and resuming surfaces.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D17960239
fbshipit-source-id: 7ae556ed91030f4c5ab187689ce6bd161fabde93
Ramanpreet Nara
Valentin Shergin
Samuel Susla
Peter Argany
Radek Czemerys
Tim Yung
Rick Hanlon
Andrew Monshizadeh
Adam Foxman
Victor Fernandez
Dratwas
Adam Ernst
