Summary: With new `ShadowTree::getRootShadowNode()` method all access to rootShadowNode_ is protected by commit mutex.
Reviewed By: mdvacca
Differential Revision: D10159456
fbshipit-source-id: 0bc8676ca2564a8ef95d60e912356e99d9f172c1
Summary:
Calling `uninstall` synchnously was a bad idea. Unfortunatelly, even if it illuminate possible race condition during uninstallation, sometimes it deadlock.
It's not clear for now how to solve both problems without introducting another layer of indirection between UIManager and JSI.
Reviewed By: mdvacca
Differential Revision: D10081500
fbshipit-source-id: 90d8120603929a8219a3e606d8b3527e297b13ce
Summary: That's why we need the previous three diffs. Synchonous executor deadlocks if the beat is missing.
Reviewed By: sahrens
Differential Revision: D10081501
fbshipit-source-id: 9986d0a1844e642048b6f37a1fcb5f623a267663
Summary: In some cases we have to have a way to notify a EventBeat consumer that the beat cannot be (and will not be) delivered, so we introducing special API for that.
Reviewed By: mdvacca
Differential Revision: D10081503
fbshipit-source-id: 4c5a392d32572f426e3744bdba797efcd29b8cb4
Summary:
All code styles are terribly ugly. We have the only choise - choise something and embrace it.
This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
Reviewed By: mdvacca
Differential Revision: D10218598
fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
Summary: This diff unifies the 'handling' of the top prefix in the EventEmitter.cpp class
Reviewed By: shergin
Differential Revision: D10149497
fbshipit-source-id: d0ddbbbeefe3790b414b101da47582161354c971
Summary: This diff renames com.facebook.fbreact.fabric.UIManager to FabricUIManager, this is done in order to avoid confusion with com.facebook.react.bridge.UIManager
Reviewed By: shergin
Differential Revision: D10128635
fbshipit-source-id: 0cb874ec1ba698077d750214f1d25004065c2f59
Summary: This diff exposes the method EventEmitter.dispatchEvent as public in order to be able to access it from the android side.
Reviewed By: shergin
Differential Revision: D10127509
fbshipit-source-id: d6ddf59c654a91fdeed5fba867ca31d6de96d607
Summary: This change implements `onLayoutOnly` for regular bare <View> component (*not* for its descendants!) After this view flattening is actually starting working for all platforms.
Reviewed By: mdvacca
Differential Revision: D9511001
fbshipit-source-id: 3562dd1b7570a064150f100cc2e1bc4220b81290
Summary:
... instead of using direction access to `ygNode.getLayout()` object.
Suddenly, YGLayout object that YGNode exposes contains unresolved/directional-unaware styles. To get resolved directional-aware styles we have to use functions from Yoga.h.
I am not happy with this solution, I will try to implement something like `ygNode.getResolvedLayout()` and use that instead.
This change fixes strange missing horizontal padding around some views.
Reviewed By: mdvacca
Differential Revision: D10112049
fbshipit-source-id: 4b6ef39d8dd34e78a4592962e8af4eeaa5028768
Summary: That should save us some app size kilobytes.
Reviewed By: mdvacca
Differential Revision: D10081499
fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Summary: We have to uninstall UIManager synchronously to avoid a race condition when JS is capable to call already deallocated UIManager.
Reviewed By: mdvacca
Differential Revision: D10033406
fbshipit-source-id: 194d1ae2dd5ab09b036b1c165de289ada8e66014
Summary:
There is no need to make JS calls to start or stop React Native apps; Scheduler does it automatically. Yay!
With this change (because we have to change Scheduler API) we are starting slow process migrating away from using term `reactRootTag` when we refer to running a ReactNative app (aka Surface). We will use `surfaceId` instead. We plan to slowly and gracefully retire `reactTag` term entity replacing it with several appropriate entities specific for particular usage, e.g. `viewId` (some id which makes sense for mounting), `surfaceId`, `nodeId` (unique id representing nodes which were cloned from the original one), or `eventTarget`.
Reviewed By: mdvacca
Differential Revision: D9999336
fbshipit-source-id: bbc7303c195b070b8c235c9ca35546d1dc693e98
Summary: This is the last step before making JSIUIManagerInstaller a direct dependency of UIManager (and making UIManager installation process completely seamless/platform-agnostic).
Reviewed By: mdvacca
Differential Revision: D9995781
fbshipit-source-id: 6f8c7177495b01ebaac1dbe330f49dce2e2a552c
Summary:
EventBeatBasedExecutor is an executor derived from EventBeat and using EventBeat to ensure proper threading.
Why do we need yet another executor? Because otherwise, we have to make it platform specific-dependency that each platform-specific implementation has to implement and provide. We already have all that we need in already provided EventBeat, so we can just convert that into simple executor in a platform-agnostic way.
Reviewed By: mdvacca
Differential Revision: D9995783
fbshipit-source-id: f8aa72a9744e50ebecbea9ad0e2546f41f5358f2
Summary: UIManager now can install and uninstall itself calling a functions that are provided as constructor arguments.
Reviewed By: mdvacca
Differential Revision: D9931329
fbshipit-source-id: b8d2d9925b0e2db0fed44bdf2e185d198fabd5ee
Summary: As it mentioned in the comment, we have to commit an empty tree as part of cleaning up Surface.
Reviewed By: mdvacca
Differential Revision: D9931320
fbshipit-source-id: 04e780bafdb917adeb89f2edef2dc0348b2a4d4a
Summary: This diff adds support for the ActivityIndicator component into the Android Fabric C++ implementation
Reviewed By: shergin
Differential Revision: D9781846
fbshipit-source-id: 952d72556983955875198ac3b7eece6868bc4ae8
Summary: This diff adds support for image views in Android
Reviewed By: shergin
Differential Revision: D9757712
fbshipit-source-id: 8d33e04c8ac4a670af6ca49bb3b9dccc69d52e40
Summary: This diff fixes the compilation error: "implicit instantiation of undefined template std::hash" when using TextAttributes in Android
Reviewed By: shergin
Differential Revision: D9849407
fbshipit-source-id: 7fcb94b1d4f7715d8037ecbf302d8f345e99e9fd
Summary: This diff introduces the concept of Local Data in Android Fabric C++ and as an example we uses it to implement Text View.
Reviewed By: shergin
Differential Revision: D9583970
fbshipit-source-id: ab7478b16ef4327ff574ca1467870ab9cb684ea0
Summary: In this diff I added support to be able to measure C++ shadowNode in Android. As an example I implemented the measurement of TextViews
Reviewed By: shergin
Differential Revision: D9583972
fbshipit-source-id: 1344782d4c586c94a4576b18a4acfa4775e46952
Summary: This diff introduces a way to convert ParagraphLocalData object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801892
fbshipit-source-id: e50217042a216ea67f28178bb80b136cbb8fb195
Summary: This diff introduces a way to convert AttributedString object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801438
fbshipit-source-id: b762f54917ae90bf53c7f9d07f63b876d1265ece
Summary: This diff introduces a way to convert TextAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9800636
fbshipit-source-id: 592f1cb60a00d3beaecee221259e8914731049d4
Summary: This diff introduces a way to convert ParagrapgAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9798895
fbshipit-source-id: 5b139a079c8681749c3e13938482b47e4153019d
Summary:
A bunch of different things was changed, but the most important (and need) change is that `UIManager` is now passed in the function as a regular reference, not as a `shared_ptr`. Besides that fact that passing this as `shared_ptr` is simply incorrect (because there is no ownership sharing/transferring here), we need this change because we cannot construct `shared_ptr` from `this` inside `UIManager` class (especially in the constructor).
Besides that:
* `const &` everything (correctness, explicit intention, performance);
* Names were unified with the rest of the code;
* `auto` everything;
* All JSI stuff is now explicitly prefixed with `jsi::`;
* `using` instead of `typedef` (modern C++ syntax);
* Lamdas instead of std::bind (same perfromance, much more clear and flexible);
Reviewed By: mdvacca
Differential Revision: D9835901
fbshipit-source-id: 935be0ae889fe5508ffa9498282c939c816587e1
Summary: In modern C++ `const` basically means `thread-safe` and we commit that all that methods are thread-safe.
Reviewed By: mdvacca
Differential Revision: D9836100
fbshipit-source-id: 4241ca80da77338b25246e622cf8d7e8c360eff7
Summary:
The spec says that `bridge_transfer` indicates that we "transfer ownership of the pointer" to ARC which implies that as soon this part of the code does not need the object, it will be deallocated. However, that's not what we want here. This object is actually already owned by another ARC-powered code somewhere else and the pointer to it was transferred as a raw pointer through the C++ world.
So, we want to keep the ownership of the object on the other side but still imply the lifetime of the object. So how can we do that? Simple, we have to use `bridge`.
Why? ARC is not magical, it's just automatic ref counting. And I think the only difference between `bridge` and `bridge_transfer` is how many refcounter's bumps will be added to the generated code. In the case of `bridge_transfer` it is zero, in the case of `bridge` it is one. So, initializing a new Objective-C variable that points to the shared resource we have to bump the counter once, so we have to use `bridge`.
Reviewed By: mdvacca
Differential Revision: D9819405
fbshipit-source-id: 9e7af343917ec4407a64d884402b10ee2a8097f9
Summary: We will need that to manage collections of attributed strings.
Reviewed By: mdvacca
Differential Revision: D9803351
fbshipit-source-id: 0ea9719f97ed30ff6dfe17b6dbebf448afe228b3
Summary: We will need this eventually.
Reviewed By: mdvacca
Differential Revision: D9799852
fbshipit-source-id: 0411e2f41540273c80f425e04c877fe51b9b2374
Summary:
I realized that instead of using shared_ptr's type-erasure feature, we can make the EventHandler's destructor virtual and this itself will allow safe deallocation by a pointer to a base class.
We cannot use the same technic for EventTarget thought because having a weak_ptr to this is another feature of shared_ptr that we need.
Reviewed By: mdvacca
Differential Revision: D9775742
fbshipit-source-id: 3c23a163827e8aa9ec731c89ce87051a93afe4ca
Summary: Instead of relying on explicit `RawEventDispatchable` function, we simply check the existence of the `weak_ptr` to `EventTarget`. This is efficient and sufficient because only an EventEmitter retains an associated EventTarget.
Reviewed By: mdvacca
Differential Revision: D9764858
fbshipit-source-id: 4ac25d925f189d0f8b9002e52388fd51629934a8
Summary:
This diff implements a new model of managing `enabled` flag in EventEmitter.
Now we simply rely on `eventTarget_` is not being `nullptr` (and we reset the pointer to "disable" the event emitter).
Reviewed By: mdvacca
Differential Revision: D9764857
fbshipit-source-id: 1dd3ce0c8589048babbf2dbac9f8359358b31a34
Summary:
As we did in the previous diff, here we implemented `EventEmitter`'s ownership model as a `shared_ptr`. This change fixes problem with leaking `WeakObject`s which happens on hot-reload.
So, in short:
* `EventTargetWrapper` object owns `jsi::WeakObject` that can be converted to actual `jsi::Object` that represent event target in JavaScript realm;
* `EventTargetWrapper` and `jsi::WeakObject` objects must be deallocated as soon as native part does not need them anymore;
* `EventEmitter` objects retain `EventTarget` objects;
* `EventEmitter` can loose event target object in case if assosiated `ShadowNode` got unmounted (not deallocated); in this case `EventEmitter` is loosing possibility to dispatch event even if some mounting-layer code is still retaining it.
Reviewed By: mdvacca
Differential Revision: D9762755
fbshipit-source-id: 96e989767a32914db9f4627fce51b044c71f257a
Summary:
Previously, we used special JSI bindings method to release an event handler (`JSIReleaseFabricEventHandler`). Now we expose this ownership model as a regular `std::shared_ptr`, so when the owner got deallocated, the event handler will be released automatically.
Why not use `unique_ptr`? `unique_ptr` is faster (and simpler) indeed, but it does not provide `type erasure` functionality that we need; to use `unique_ptr` we would have to make JSI an explicit Fabric dependency (we will probably end up with it eventually, but I this particular case is not a good reason for that).
All interactions with `eventHandler_` are done in a non-owning manner, so it's as performant as unique_ptr anyway.
(Please ignore all changes in JSCFabricUIManager.h/cpp files, we will delete them soon.)
Reviewed By: mdvacca
Differential Revision: D9756732
fbshipit-source-id: bffdee0c724dc95855ced7c35e7c13cf1554796e
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
Summary:
When text nodes are nested, as below, `onPress` handlers need to be correctly invoked:
```
render() {
return (
<Text onPress={() => console.warn('hi')}>
hi
<Text onPress={() => console.warn('ramanpreet')}>ramanpreet</Text>
</Text>
);
}
```
In the above example, clicking on "hi" should warn "hi", and clicking on "ramanpreet" should warn "ramanpreet". This diff implements that behaviour.
Reviewed By: shergin
Differential Revision: D9696905
fbshipit-source-id: 2daf24e76c3b3c37aa36cd1540e54876a367faf7
Summary:
This diff includes two changes:
1. `TextShadowNode` represents virtual texts. For the time being, virtual text nodes only need touch capabilities so that they can handle `onPress` events for their children. Therefore, we should set the `TextShadowNode`'s `EventEmitterT` to `TouchEventEmitter`.
2. Since `ParagraphShadowNode` extends an instance of the `ConcreteViewShadowNode` template, it automatically uses the `ViewEventEmitter` if no event emitter is specified. I think it's better to make the event emitter explicitly specified. So, I've included that change in this diff.
Reviewed By: shergin
Differential Revision: D9696906
fbshipit-source-id: ac053ffdde4c2fbc6351f177c07a2ada4445cbb8
Summary: In the future, we may want some components (like Virtual Text) to handle only touch events. Therefore, I've extracted `TouchEventEmitter` from `ViewEventEmitter`.
Reviewed By: shergin
Differential Revision: D9696903
fbshipit-source-id: f6acc90d8ff53b5e6badaa472a5e099fb7cf03ff
Summary:
When a user clicks on some text, `RCTSurfaceTouchHandler` will call into a method on `RCTParagraphComponentView`. That method (i.e: `touchEventEmitter`) would be responsible for identifying the closest ancestral `<Text/>` component to which we should dispatch the `onPress` event, given the point where the user clicked. To answer this query, we'll use a data structure called `UIAttributedString`.
This data structure represents a string, and a corresponding mapping from sequences of its characters to some arbitrary data. In this attributed string, we'll map sequences of characters to their closest ancestral `ParagraphShadowNode` or `TextShadowNode`. That way, when we get a click event on `RCTParagraphComponentView`, we can just look at the character that was clicked, and use that information to do a lookup in the attributed string to find the shadow node who's EventEmitter is responsible for processing the click event.
Reviewed By: shergin
Differential Revision: D9696904
fbshipit-source-id: a199649981ad271afa85414ce4c3f056851348be
Summary: Previously, `BaseTextShadowNode::getAttributedString` used to recurse on a list of `SharedShadowNode`s (i.e: the children). In the `RawText` base case of this recursion, we'll need to record the parent of the current `RawText` (so that we can dispatch the `onPress` event to it). Therefore, we need to start recursing using the `SharedShadowNode` itself, and not its children.
Reviewed By: shergin
Differential Revision: D9696908
fbshipit-source-id: dbf3f9c21a7ae4de421d0355c4e5900b3947dc2a
Summary:
@public
Trivial.
We should not use the name of the effort in the API interfaces where it's not neccecery.
Reviewed By: sahrens
Differential Revision: D9652991
fbshipit-source-id: 52b99e39f92926f9fc99626690eb4385195558f6
Summary:
@public
Now we simply skip `uiManagerDidFinishTransaction` calls if they refer to unregister surfaces. In the future, after we have proper asynchronous scheduling and sync unmounting (and if we chose to have sync unmounting), we can avoid this situation (and assert in this cases).
Reviewed By: sahrens
Differential Revision: D9652731
fbshipit-source-id: e376ea1ae4f93960a903e6397d843bd7c4b72400
Valentin Shergin
David Vacca
Scott Rice
Héctor Ramos
Ramanpreet Nara