Summary: missing header and platform. attributedstring builds now, but still fails because of T34990592
Reviewed By: mdvacca
Differential Revision: D10349210
fbshipit-source-id: dcd163df9ac9a4fcb36399cb9f93dbf1b33c062d
Summary: Simplies UIManager a bit and some other tweaks
Reviewed By: shergin
Differential Revision: D10211883
fbshipit-source-id: 93ab23dd2baab2fdc6d9c54e976b001a19efab7f
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: Quite obviously, having a `complete` method which accepts only `newRootShadowNode` was a baaad idea. When we `complete` or `commit` we always have to have two nodes (before and after). And only after layout and right before swapping (and acquiring the mutex) we have to verify that *current* root node is still the same as it was when we initialized the transaction (if not, we have to abort).
Reviewed By: mdvacca
Differential Revision: D10201902
fbshipit-source-id: 15adc78c5d31d6fd39fd7fc6e53203a5539717a8
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
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 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: 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:
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:
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:
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:
@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
Summary:
@public
We don't need this anymore.
The same functionality is now implemented as `ShadowView::operator==` in much more reasonable way.
Reviewed By: sahrens
Differential Revision: D9649821
fbshipit-source-id: 8cd5f3cb4f583fd10d2d1e060aba914541341b5b
Summary:
@public
Apparently, it's how it should be.
Reviewed By: rsnara
Differential Revision: D9631870
fbshipit-source-id: 46f58270104d699fbc9abe21062c12f791460536
Summary:
@public
Now it's clear that we don't need to store/handle ShadowTree objects as `shared_ptr`s; Scheduler should own it. This diff changes that to using unique_ptr and removes a base class of ShadowTree.
Reviewed By: mdvacca
Differential Revision: D9403567
fbshipit-source-id: 6e411714b632a04233fd5b25c8ab7cdd260105fd
Summary:
@public
Voalá, this small change actually implements view flattening. Obviously, it does not work right now because there are no `ShadowNode` classes which implement `isLayoutOnly`.
Surprisingly, correct implementing of `isLayoutOnly` is quite tricky, we will work on this in coming diffs.
Reviewed By: mdvacca
Differential Revision: D9403565
fbshipit-source-id: 1f16f912cb5c6841405a1fc3cf36aec28698c11f
Summary:
@public
This is quite a big diff but the actual meaningful change is simple: now we use ShadowView class instead of ShadowNode in mutation instructions.
Note:
* In some places (especially during diffing) we have to operate with ShadowNodeViewPair objects (which represents a pair of ShadowNode and ShadowView). The reason for that is that we cannot construct child ShadowViews from parent ShadowViews because they don't have any information about children.
* `ShadowTree::emitLayoutEvents` is now much simpler because ShadowView better represents the specifics of this kind of object.
* The code in RCTMountingManager also became simpler.
This change will allow us to implement more cool tricks soon.
Reviewed By: mdvacca
Differential Revision: D9403564
fbshipit-source-id: dbc7c61af250144d6c7335a01dc30df0005559a2
Summary:
@public
We need some another object like ShadowNode (but not ShadowNode) to represent an instance of the component in the mutation instructions. This is
the main motivation for introducing ShadowView.
Why not use ShadowNode? ShadowNode is designed to represent a node in ShadowTree, not be a part of a mutation instruction.
* ShadowNode exposes some APIs that should not be exposed to the mounting layer;
* ShadowNode is an immutable data structure, so we cannot mutate it in some way which can be meaningful for mounting;
* We should not add to ShadowNode any functionality which is needed only for mounting;
* ShadowNode is a bit more heavy object to share that it needs to be; it's exposed (embedded into Mutation) as a `shared_ptr` which is not optimal from the performance perspective;
* Retaining ShadowNode from mounting code can unnecessarily extend its lifetime which can negatively affect memory usage.
Reviewed By: mdvacca
Differential Revision: D9403562
fbshipit-source-id: 72ad81ed918157a62cd3d1a03261f14447649d0b
Summary: This diff implements the HorizontalScrollView component for Android Fabric C++, as part of this diff I also re-named the components AndroidHorizontalScrollContentView for RCTAndroidHorizontalScrollContentView and AndroidHorizontalScrollView for RCTAndroidHorizontalScrollView. This might sound against our plan of removing the RCT preffix, but it is to make it simpler to map components between current implementation of RN and Fabric (otherwise we don't know when to add the RCT preffix in Android side to find the right View Manager), later we can just remove the preffix from C++, Android, iOS and JS.
Reviewed By: shergin, achen1
Differential Revision: D9122729
fbshipit-source-id: e9299552857c6dd0c18abfa5fa49a3d50e221729
Summary:
@public
Now, it's not just an abstract class, it's a regular class which unifies event delivery priorities using specific event beats and event pipe.
Reviewed By: mdvacca
Differential Revision: D8886232
fbshipit-source-id: c4360511e5fd477ca7407fc3ebbd99ca578e79cc
Summary:
@public
We need that to ensure that we will not deliver events to nodes with invalid state.
Reviewed By: mdvacca
Differential Revision: D8886234
fbshipit-source-id: 1d6ca129c97a5dca0411e85909aea48185f46c54
Summary:
@public
Instead of having two methods it's easier to have just one which can be abstracted as `EventPipe`.
Reviewed By: mdvacca
Differential Revision: D8886231
fbshipit-source-id: af9fd92dc4afa1219a11acce0aa021a85c94d232
Summary: This diff improves the error message that is displayed when a component descriptor is not implemented in C++
Reviewed By: shergin
Differential Revision: D9093562
fbshipit-source-id: 930b381bc66c20af6fa160b09e7484bad4666e28
Summary:
@public
To avoid unnecessary copying of `shared_ptr`s inside ShadowNodeFragment, now we store them as `const &` references.
Reviewed By: mdvacca
Differential Revision: D8988388
fbshipit-source-id: 0b3582e57ce7577b8fa819392bf33f34e1a60b59
Summary:
@public
Now we use same data structure to specify a shape of shadow node as we use in ShadowNode (sub)clases.
Reviewed By: mdvacca
Differential Revision: D8988387
fbshipit-source-id: 475298b2c71ee7ee2b197db009f7b8313b54f5df
Summary:
@public
When we copy-construct ShadowNode, we don't need to retain a source shadow node, so there is no need to pass it as a `shared_ptr`. Passing an argument to constructor as `const &` is also more idiomatic in C++.
Reviewed By: mdvacca
Differential Revision: D8988384
fbshipit-source-id: 1279d9185fa1b4b82fd26e3040bd62fa9495b4d3
Summary:
@public
This diff changes a way how we specify a shape of newly created and/or cloned of ShadowNode. Previously we pass those values as a list of arguments, now those values are coupled into a new data structure called ShadowNodeFragment. All that makes suppose to make code much more easy to read and maintain, this is especially important because we want to add a couple of new entities in this set.
Reviewed By: mdvacca
Differential Revision: D8988389
fbshipit-source-id: 1835f646e1ecc6a1f413feaf1900f3d3ad0ebc05
Summary:
@public
Previously, ContextContainer could store only `shared_ptr`s, but now it wraps all values in own `shared_ptr` container.
I wish we can use `unique_ptr` here, but apparently we cannot because `unique_ptr` does not support type-erasure (`std::unique_ptr<void>` is illigal).
Becasue ContextContainer is not supposed to be used in hot paths, the performance aspect of that does not actually matter.
Reviewed By: mdvacca
Differential Revision: D8853446
fbshipit-source-id: e5d0a5595fe44c59f1395d6ffccf9d3fed923c83
Summary:
@public
We need that because gonna add much more event-related stuff, so it deserves separate buck target.
Reviewed By: mdvacca
Differential Revision: D8831547
fbshipit-source-id: 616581b39b425a49302d5f7f86267e62b0d58389
Summary:
@public
We need this in case when we want to store several intances of the same class in the container.
Reviewed By: mdvacca
Differential Revision: D8814808
fbshipit-source-id: 78ab15d78cf3878d03bf0a45bc42b968d87435e7
Summary:
@public
There is no reason to have it inside View; it deserves that.
Reviewed By: mdvacca
Differential Revision: D8757012
fbshipit-source-id: 881b54008b51614cd203ab97811494fa7c30e4ef
