Summary: Adds support for dynamic value that are `std::vector<std::vector<RawValue>>`
Reviewed By: shergin, mdvacca
Differential Revision: D16936932
fbshipit-source-id: fc8d087f9705af9da56ccc1bd9a0537b2bfeb50d
Summary: We used this mechanism at the very early stages of Fabric. Now we do component registration differently.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17200952
fbshipit-source-id: 16ff9d6569714a24e2a8d58dc6e60ad4d7bc1e16
Summary: This allows to implement `findNodeHandle` in Fabric world (temporary).
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175953
fbshipit-source-id: c88bd1c58608450812799d4ecb4a6bf2c027c5f3
Summary: The mehtod implements the core functionality of finding a shadow node by given tag.
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175955
fbshipit-source-id: 5cfbb80b2d4e54a33ca9c20a21988df4de54c800
Summary: The new methods provides a way to iterate over all registered shadow trees.
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175954
fbshipit-source-id: e4e6ee5a0e0a4e4e36b99d546f8724b99559c8c2
Summary:
We don't need to have those methods virtual anymore.
Nowadays we have a pointer to a `ComponentDescriptor` in `ShadowNode`, it's simpler to get that value from there.
That's also more code-size friendly because we now can remove those methods from a template.
Reviewed By: sammy-SC
Differential Revision: D17142173
fbshipit-source-id: 9f54fbe6c1ebad3ed49843ed75a01ca5ee48c34f
Summary: We merge `events` module into `core` long time ago, so we don't need this anymore.
Reviewed By: mdvacca
Differential Revision: D17142174
fbshipit-source-id: 6e63f7f22dc3d65ed2f9cc3bd4f4776404dfe788
Summary:
The type is wrong in the constructor.
build-break
Differential Revision: D17145039
fbshipit-source-id: f6b80e38c05e60f04d029aa34baa0c55c237a39a
Summary: Support existing, backwards-compatible AndroidTextInput component for minimal support of TextInput on Android.
Reviewed By: shergin, mdvacca
Differential Revision: D17086758
fbshipit-source-id: 25726f22229e0d5dfe96eb36b386a5317601283d
Summary:
The purpose of `EventBeat` is handling an asynchronous callback to itself which is being delivered on some different thread. That brings a challenge of ensuring that the `EventBeat` object stays valid during the timeframe of callback execution. The concept of Owner helps with that.
The owner is a shared pointer that retains (probably indirectly) the `EventBeat` object. To ensure the correctness of the call, `EventBeat` retains the owner (practically creating a retain cycle) during executing the callback. In case if the pointer to the owner already null, `EventBeat` skips executing the callback.
It's impossible to retain itself directly or refer to the shared pointer to itself from a constructor. `OwnerBox` is designed to work around this issue; it allows to store the pointer later, right after the creation of some other object that owns an `EventBeat`.
Reviewed By: JoshuaGross
Differential Revision: D17128549
fbshipit-source-id: 7ed34fd865430975157fd362f51c4a3d64214430
Summary:
Seems it's more logical and safe to store ShadowTreeRegistry in UIManager than in Scheduler. We also probably will move some functionality dealing with the registry to UIManager.
But most importantly we need it to manage the ownership properly. UIManager might overlive Scheduler and still get a call to process a shadow tree. In the current configuration, it causes a crash because the registry owns by Scheduler. Moving that to UIManager solves that.
Reviewed By: JoshuaGross
Differential Revision: D17128550
fbshipit-source-id: e6735acaa11f2ed82ca17f18a45e389d79aa1a08
Summary:
This diff changes the way how `UIManager`, `UIManagerBindging`, `Scheduler` and `EventDisaptcher` refer to each other which should help with stability and reliability.
Here is the node that describes the details:
# Retaining dilemma
# Players
We have many logical of moving pieces but most of them can be abstracted by following high-level components.
* **Scheduler**
`Scheduler` is the main representation of running React Native infrastructure. Creation of it means the creation of all React Native C++ subsystems (excluding RuntimeExecutor) and destruction of that means the destruction of all dependent parts. Both processes must be thread-safe.
* **UIManager**
UIManager is a module that contains the most high-level logic of managing shadow trees. All React Renderer calls are practically implemented there.
* **UIManagerBinding**
UIManagerBinding is a representation (aka `HostObject`) of UIManager in the JavaScript world.
* **EventDispatcher**
EventDispatcher is a class that implements all logic related to dispatching events: from calling event on any thread anywhere to executing a particular JavaScript handler responsible for handling that event.
Instances of those classes have complex relationships in terms of owning each other, order of creation and destruction. The configuration of these relationships is dictated by a set of constraints that those classes need to satisfy to be constructed, accessed, and destructed in a hostile multithreaded environment. Messing with that can cause deadlocks, random crashes, suboptimal performance or memory leaks. Make sure you consider all constraints and requirements before changing that.
# Goal
We need to have a safe and reliable way to construct and destroy those objects (on any thread, in any random moment). Keep in mind that all of those objects are being accessed from random threads and have random states in any particular moment. Switching threads happens all the time, so having some state in one place does not guarantee any state in other places.
# Caveats
Let's discuss all concrete constrains that the moving pieces have to satisfy.
* **UIManagerBinding is a HostObject**
Practically that means:
1. It must be constructed "on JavaScript thread" (with exclusive access to JavaScript VM);
2. It must not be retained by other parts of the system because overliving the VM will cause a crash.
3. It can be destructed on any thread (VM does not give any guarantees here). The particular configuration guarantees that the destruction cannot be run concurrently with any JS execution though (because we never clear the reference to the host object from JavaScript side).
* **UIManager needs to be connected with UIManagerBinding and vice-versa**
Those to modules call each other to perform some UI updates or deliver events.
* **Scheduler can be deallocated on any thread at any time**
Timing and thread are up to the application side. The Scheduler must be resilient to that.
* **EventDispatcher can call UIManager at any time**
Luckily, that happens only on JavaScript thread.
* **Using weak pointers cames at a cost**
`std::weak_ptr` is a concept for managing the non-owning relationships in a safe manner. Dereferencing such pointers cames at a cost (additional object construction and atomic counters bumps). So, we should use that carefully; we cannot use shared and week pointers everywhere and assume that will work magically.
# How does this blow up?
Without describing the current configuration, here are a variety of cases that we currently observe.
1. `Scheduler` was deallocated and destroyed UIManager but VM is still running. The VM calls the UIManagerBinding, UIManagerBinding calls a method on already deallocated UIManager. Boom.
2. VM is being deallocated and deletes all host object as part of this process. Some UI event is sill in flight on some thread. The event retains UIManagerBinding via UIManager. VM cannot destroy UIManagerBinding because it's being retained. Boom.
3. VM was deallocated. `Scheduler` was deallocated. But some native state update is still in flight. It retains EventDispatcher and eventually trying to access some shadow tree that was retained by Scheduler and already dead. Boom.
That's pretty much routine endless nightmare of any low-level framework. Luckily, the good proper decisions (and iterating on that!) can solve that.
# Proposed configuration
The configuration is based on those ideas:
1. Never retain `UIManagerBinging`.
2. Never recreate `UIManagerBinging`. Create once and load lazily from JS environment on demand.
3. Consider UIManager as an object with shared ownership between JS and native. That object must be able to overlive native infra or JS VM.
4. Use EventDispatcher as a single weak representation of the JavaScript world; Never retain it strongly except by the Scheduler.
5. `UIManagerBinging` and `UIManager` can be attached or detached. `UIManagerBinging` retains `UIManager`, `UIManager` does not retain `UIManagerBinging` back. Destroying `UIManagerBinging` nulls the raw pointer to that from `UIManager`.
6. All calls from native to JavaScript can validate the pointer from `UIManager` to `UIManagerBinging` to check that the call is possible. All that calls happen on JavaScript thread.
## Stages
* **Creation process**
Creation Scheduler creates `UIManager` and scheduler asynchronous call to JavaScript to create `UIManagerBinding` and attach them. At the same time `Scheduler` creates `EventDispatcher` and makes it retains `UIManager`.
* **JavaScript-to-native invocation**
`UIManagerBinding` has a shared pointer to `UIManager` and can cheaply and safely verify that the pointer is not nullptr. Any mutation of this pointer happens on the JavaScript thread or effectively on VM destruction (non-concurrently).
* **Native-to-JavaScript invocation**
The invocation starts from retaining `EventDispatcher` (converting a weak pointer to strong one), that retains `UIManager`. Later, on the JavaScript thread, `UIManager` checks the raw pointer to `UIManagerBinding` to verify that the call can be performed safely.
# Easy ways to break the fragile balance
- Never retain `EventDispatcher` as a shared pointer. That causes a leak of UIManager and associated resources.
- Access a shared pointer to `UIManager` by value only. The simple way to break that is to specify `[=]` capture block for a lambda and access an instance variable pointing to a `UIManager` (that does not retain the pointer; make a copy on the stack and copy that to the lambda).
Reviewed By: JoshuaGross
Differential Revision: D17120333
fbshipit-source-id: 83138657683e91ceb2f48f18f30e745199c83e82
Summary: We don't use it anymore. (And that was debug only concept.)
Reviewed By: sammy-SC
Differential Revision: D17115538
fbshipit-source-id: 20aac5457e37666cbf9ca9f62cdfca411026c219
Summary: We don't use it anymore.
Reviewed By: JoshuaGross
Differential Revision: D17115539
fbshipit-source-id: e1fa5cc023cd27e53307aa0ea8eae0bad5413be3
Summary: Storing a strong shared pointer to `ComponentDescriptor` can cause a memory leak. Therefore we enforce all call sides and params to be weak pointers. The only Scheduler preserves a retaining pointer to it (to prevent preliminary deallocation).
Reviewed By: sammy-SC
Differential Revision: D17115540
fbshipit-source-id: fdea7d19f742ff04d5ba5470dd9748a5b226aa7c
Summary: That was always part of design, that's okay to get a newer state from any other state. We will need it in the future diffs.
Reviewed By: sammy-SC
Differential Revision: D17053429
fbshipit-source-id: 2174e7d6e3a1ed231f7f6e238d216d0b09ec8797
Summary:
It's okay in Fabric model to commit some subtrees which are kinda obsolete (that's strange but technically it's not against the model), but it's not okay to commit some states that were already committed before.
This diff prevents that.
Reviewed By: JoshuaGross
Differential Revision: D17053428
fbshipit-source-id: fb3536312163b7b57011647b4ba7b931c2179d89
Summary: This diff adds support from `ScrollView::scrollEventThrottle` property on iOS.
Reviewed By: JoshuaGross
Differential Revision: D17000397
fbshipit-source-id: 93f23919a6a2588000c0eeca869171d1036348b6
Summary: There's an old hack in the C++ code that prevents TextInputs from being rendered by forcing them to render as Views instead. We don't need this anymore.
Reviewed By: shergin
Differential Revision: D16932795
fbshipit-source-id: 347df106f638c2bf936e2312f42bcb9310d72c6d
Summary:
This diff moves RCTImageLoader, RCTImageEditingManager, and RCTImageStoreManager to CoreModules. This is necessary for us to convert all these NativeModules to TurboModules.
**Note:** As a part of this diff, I had to break apart `RCTImageLoader.h`. All the protocols that were in `RCTImageLoader` are now in their own headers. Furthermore, `RCTImageLoader`'s methods are defined in `RCTImageLoaderProtocol`, so that we can call them from classes like `RCTImageViewManager` in `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D16805827
fbshipit-source-id: 89f6728b0766c30b74e25f7af1be8e6b8a7e6397
Summary:
Fragment was assigned incorrect `tag` and `surfaceID` (`surfaceID` is the important one).
Wrong `surfaceID` means that `navigationCoordinator` is never resolved. As a result of navigationCoordinator not being assigned, tapping a video ad on Marketplace results in showing video ad overlay rather than showing full screen video.
Reviewed By: JoshuaGross
Differential Revision: D16646492
fbshipit-source-id: 0da5c56ecb7c81e9f4a9469a3626ccd430a01558
Summary: This diff implements the JSResponderHandler methods in the core of RN (scheduler API and friends)
Reviewed By: ejanzer
Differential Revision: D16543437
fbshipit-source-id: dac03e30c4330d182ecf134f3174ba942dbf7289
Summary:
This diff changes the name of the DispatchCommand methods in the UIManagerDelegate and Scheduler classes.
The purpose of this change is to use a consistent naming with the rest of the methods od these classes.
We might re-name these interfaces later, but for now we want to keep a consistent naming. For more details see discussion in D16543437
Reviewed By: JoshuaGross
Differential Revision: D16575403
fbshipit-source-id: 8335be8dc3367372a8ef2d7e8ed78665f4c02699
Summary: I think it's possible that there's a race condition between creating the scheduler and setting the delegate leading to bugs like T47272192.
Reviewed By: mdvacca
Differential Revision: D16537737
fbshipit-source-id: 9c579537658be5a9aeed37c0e4935c997cabb6aa
Summary:
# Problem:
I enabled Fabric for "Profile About", when I navigate to "Marketplace Home" from "Profile About", I get following warning "<Component> is not Fabric compatible yet". Even though the component has been migrated to Fabric and is getting registered. The component works if I navigate straight to "Marketplace Home".
{F172219008}
# How it was solved:
It turns out, there was a missing call that added newly created registry to `componentDescriptorRegistries_`.
Reviewed By: shergin
Differential Revision: D16542109
fbshipit-source-id: 22a315333cfff0895ce77e8439816f4e7bf34d35
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).
This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.
However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.
This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.
This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.
## Changelog
I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816
Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: hramos
Differential Revision: D16495030
Pulled By: fkgozali
fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary: Right now RuntimeExecutor is only used in Fabric. Moving it out of Fabric's uimanager/primitives.h and into react/utils so we can use it more broadly.
Reviewed By: shergin
Differential Revision: D16385366
fbshipit-source-id: 96063e536e1480bac078a9376fe55f7d8750477e
Summary: This diff exposes the legacy measure() method on Fabric. This method will be replaced by getRelativeLayoutMetrics in the future, but we are exposing this in order to make Fabric migration easier.
Reviewed By: JoshuaGross, shergin
Differential Revision: D16432928
fbshipit-source-id: 25cc21fb48ec0749081f112af9230bfe53314d6b
Summary: This diff exposes the new methods SetJSResponder and clearJSResponder in the UI ManagerBinding interface
Reviewed By: shergin
Differential Revision: D16420689
fbshipit-source-id: 606bede1de6b9d5fd5a56e832ad27100b6998c55
Summary: Supporting View Manager Commands on the new UIManager in Fabric. This is needed for things like scrollTo on ScrollView.
Reviewed By: JoshuaGross
Differential Revision: D16175575
fbshipit-source-id: a74effdf7e47b56a150a4e3fb6c4d787659e0250
Summary: Right now we register ReactFabric as a callable module with the bridge so that we can call `ReactFabric.unmountComponentAtNode` in `ReactInstanceManager.detachViewFromInstance`. In bridgeless mode we don't have callable modules, so I'm just setting a global variable that can be called from C++ instead. Using this in a new `unmount` method in FabricUIManager.
Reviewed By: shergin, mdvacca
Differential Revision: D16273720
fbshipit-source-id: 95edb16da6566113a58babda3ebdf0fc4e39f8b0
Summary:
Remove check whether `measureCache_` is nullptr. It was part of the experiment
which is no longer running.
Reviewed By: shergin
Differential Revision: D16360332
fbshipit-source-id: 2fc8baa93a87754da6255bf1c134901447349f7a
Summary:
`stubViewTreeFromShadowNode` was implemented without using `calculateShadowViewMutations` (aka Diffing algorithm).
The problem is that we use `stubViewTreeFromShadowNode` to test the diffing, so it was not fully correct to use the algorithm to test itself.
Reviewed By: JoshuaGross
Differential Revision: D16342526
fbshipit-source-id: 2674245ed5ec71309fe5d362779a33d8dd31dc7b
Summary: That's extremly helpful for debugging, it allows to see the generated view structure (as diffing sees it).
Reviewed By: JoshuaGross
Differential Revision: D16342528
fbshipit-source-id: bc303d5cab992e517b7cf29962d7c1232e8aeec7
Summary:
1. The check is now correct.
2. Now we call that "Invalid", not "Empty" because this case is invalid indeed.
Reviewed By: JoshuaGross
Differential Revision: D16342527
fbshipit-source-id: 433f6c5759d2d0756d55acb057b5639a8eab2e5d
Summary:
Trivial.
Before that we didn't have a way to get a root node from a Tree object.
It's useful during debugging (and some coming changes use that).
Reviewed By: mdvacca
Differential Revision: D16342529
fbshipit-source-id: 27c7516f3b3fccc8d8b25d4d2748006f7958ae41
Summary:
This diff fixes the parsing of the textAlign prop in Fabric. The current parsing does not support 'justify' or 'auto' values.
See https://facebook.github.io/react-native/docs/0.59/text-style-props#textalign for more details about the values of these props in the JS side.
Reviewed By: shergin
Differential Revision: D16269509
fbshipit-source-id: e0d9168d6022245430de644f7c4e45c968b1326b
Summary: That should help to fail early in situations when we lose critical class data members.
Reviewed By: sammy-SC
Differential Revision: D16179539
fbshipit-source-id: da73b81568c2f3657b9bc2bd1cc7ee6624e75626
Summary: This is a very similar mechanism that we use in UIManager and it should be eventually unified.
Reviewed By: sammy-SC
Differential Revision: D16179524
fbshipit-source-id: 7c8c45b7581ac4a1db3a773d62004ff368f18321
Summary: Accessibility is essential but seems we don't have any use of AccessibleShadowNode in Fabric.
Reviewed By: sammy-SC
Differential Revision: D16139595
fbshipit-source-id: a6aec6d22c4a6050d7ee5e6b21ef4ad04d80ffce
Summary:
All props to Eric Lewis! cc ericlewis
This revert of revert of land of changes originally published in #24873 (with some slight fixes). The change removes usage of LocalData from the `<Text>` component.
After this change we only have ---one (maybe two)--- three components left using LocalData.
Reviewed By: mdvacca
Differential Revision: D15962376
fbshipit-source-id: 19f41109ce9d71ce30d618a45eb2b547a11f29a2
Summary: This diff exposes LayoutDirection as part of UpdateLayoutMountItem
Reviewed By: JoshuaGross
Differential Revision: D16060521
fbshipit-source-id: 163bf2a0bdca62dcecb03a8aaa2f4bf595b18c8f
Rick Hanlon
Valentin Shergin
Joshua Gross
--fbcode@fb.com
Ramanpreet Nara
Samuel Susla
David Vacca
James Treanor
Emily Janzer
Min ho Kim
Eli White