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:
ComponentName is used by many core component of React Native, such as ComponentDescriptor, ShadowNode, ShadowView and so on. In all those cases this value represents the actual name of the component which came from `concreteComponentName` template parameter of ConcreteShadowNode. In all of those cases, it's raw `char const *` type. So, we don't need to use owning representation of the string (std::string) in all those places.
The only exception from this is a part where we receive the name of the component from JS side. In this case, the source string comes from JS and has to be analyzed as a character sequence to find corresponding ComponentDescriptor.
In my experiments, 20% of the time during diffing is spent on copying (this) `std::string`.
Reviewed By: mdvacca
Differential Revision: D15844407
fbshipit-source-id: a2e71505e22d09107e001bdf661d4a826bcf2dea
Summary:
This diff reimplements the prop parsing infrastructure in a part where it interacts with RawProps value.
Local synthetic tests show that the new way is 3x faster but the actual production result is quite unpredictable. MobileLab tests show some improvements about 10-20 ms on iPhone 6.
In short, the new way is faster because it inverts the lookup order and heavily relies on actual data types (and their properties) that we use. The old approach required about 130 hash-map lookups (where the key is `std::string`) to parse a single *Props object.
The new approach prepares concrete-props-specific tables with indexes of coming values ahead of time, iterates over raw data and puts it into those tables, and then performs a lookup in a very efficient manner.
Reviewed By: JoshuaGross
Differential Revision: D15752968
fbshipit-source-id: 847106e652eb7fc7ef7b99884a6f819ea3b9fd06
Summary:
Trivial.
We are replacing rootTag with surfaceId according to the plan describing here: https://fb.workplace.com/groups/rn.fabric/permalink/1374002366064519/
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15039134
fbshipit-source-id: ec8c3044f9f3f23939488bc01c66e9b653e651dd
Summary:
ShadowNodeFamily is a new concept that allows us to implement an efficient way to solve the problem of finding a path to some ancestor node (practically reimplement ShadowNode::constructAncestorPath() in some efficient way).
This diff is the first one in the series. It introduces a new class and moves some data into it.
Reviewed By: JoshuaGross
Differential Revision: D14416947
fbshipit-source-id: c93865a8929a2128498e34d3589487696aac6283
Summary:
SharedShadowNodeList is one of the core collections in Fabric. Every ShadowNode has one, it's used intensivly during diffing and so on.
Usually, nodes have a very few children, so using `small_vector` instead of regular `vector` should save us a lot of memory allocations.
Reviewed By: JoshuaGross
Differential Revision: D14249201
fbshipit-source-id: 53297caa027a74099d0a1ed4a3cce78f8feb651b
Summary:
This pull request removes the designated initializers in `ShadowNodeTest.cpp`. This will help improve the portability of this file.
[General] [Fixed] - Removed designated initializers in `ShadowNodeTest`
Pull Request resolved: https://github.com/facebook/react-native/pull/23714
Differential Revision: D14305162
Pulled By: shergin
fbshipit-source-id: 81803652ece734a9b223d7a8b462a8b62cde7d1d
Summary: That should reduce the size of `ShadowNode`, make an instantiation of shadowNode a bit faster, and make `clone` operation a bit faster because simple dynamic dispatch is faster than std::function invocation. It also should help a bit with code size.
Reviewed By: mdvacca
Differential Revision: D14249200
fbshipit-source-id: c1332b139d27becebf15cd894475507b5fd0eb9f
Summary:
Our long-term plan is to completely illuminate `jsi::Value`-to-`folly::dynamic` serialization step in prop parsing process improving performance and memory pressure. At the same time, we don't want to introduce a hard dependency in application code to JSI because it exposes direct access to VM and prevents parsing some data that come *NOT* from JSVM.
RawValue is an extremely light-weight (hopefully fully optimized-out) abstraction that provides limited JSON-like and C++-idiomatic interface.
The current particular implementation is still using `folly::dynamic` inside, but I have fully JSI-powered one which will replace the current one right after we figure out how to deal with folly::dynamic-specific callsites. Or we can implement RawValue in a hybrid manner if a code-size implication of that will be minimal.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D13962466
fbshipit-source-id: e848522fd242f21e9e771773f2103f1c1d9d7f21
Summary:
We have to have a way to backtrack a pointer to a parent node and this is generalized version of that.
This is the first naive implementations of the algorithm. We will invest in optimizing this later.
Reviewed By: mdvacca
Differential Revision: D12920856
fbshipit-source-id: 9facb4e16a0b5608feb6747df3804952025ef093
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
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
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
Now it accepts `const ShadowNode &` instead of `std::shared_ptr<const ShadowNode>` which is more reasonable (and more performant) becasue the function must not retain ownershipt.
Reviewed By: mdvacca
Differential Revision: D9073921
fbshipit-source-id: c24c475615e0f81b3e004e118dea7565d8e757b4
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, all ConcreteShadowNode subclasses had to override `getComponentName()` function to specialize a name of the component. And often it was all that those subclasses do. Now, it's a template argument; and many ShadowNode classes can be created as oneliners via *just* specializing ConcreteShadowNode template.
Unfortunately, C++ does not allow to use `std::string`s or string literals as template arguments, but it allows to use pointers. Moreover, those pointers must point to some linked data, hence, those values must be declared in .cpp (not .h) files. For simplicity, we put those constants in Props classes, (but this is not a strong requirement).
Reviewed By: mdvacca
Differential Revision: D8942826
fbshipit-source-id: 4fd517e2485eb8f8c20a51df9b3496941856d8a5
Summary:
@public
This diff consists of many interdependent changes which support one simple idea: YogaLayoutableShadowNode is now using YGNode children to iterate on them (it previously relied on `ShadowNode::getChildren()`). All other changes are just an unavoidable consequence of that. Hence we don't need to filter child nodes every single time when we do layout anymore! The logic around `clone callback` is also drastically simpler now.
The new approach also implies that `LayoutableShadowNode` and `YogaLayoutableShadowNode` don't use `shared_ptr`s to refer to ShadowNode objects because new relationship does not imply ownership. No more `SharedShadowNode` objects in those two classes.
Reviewed By: mdvacca
Differential Revision: D8796159
fbshipit-source-id: 6f52f92d1826f3eb13b2f8a132c3ea77de155d82
Summary:
Using `EventHandlers` name was a bad idea, and I cannot tolerate it anymore.
The worst part of it is that when you have a collection of `EventHandlers` objects you cannot use plural word to describe it because `EventHandlers` is an already plural word.
And, this object is actually an event emitter, the thing on which we call events.
Reviewed By: fkgozali
Differential Revision: D8247723
fbshipit-source-id: b3303a4b9529bd6d32bb8ca0378287ebefaedda8
Summary: This implements `EventHandlers` abstract class (aka "Events Guy") which encapsulates `eventDispatcher` and `instanceHandle` (and ownership of future `eventTarget`), all of this as part of existing {ShadowNode + Props + LayoutMetrics + LocalData + Descriptor + (and now) EventHandlers} infra. (We don't plan to add anything else to this model. Ever.)
Reviewed By: fkgozali
Differential Revision: D8053351
fbshipit-source-id: 1dd9ccbcbe5a2eb284b59ea351dc8beca645e8bf
Summary: We don't use them at all; moreover they complicate adding/changing signatures of those methods (because arguments with defaults must be grouped at the end and some arguments cannot have defaults).
Reviewed By: fkgozali
Differential Revision: D7981456
fbshipit-source-id: d7dd098e83630d1ab3342d2ca52ade9c4e27b2c3
Summary:
This diff contains several tight to each other changes (which can/should not be split into several diffs):
* The props parsing/conversion process was de-virtualized: we don't use virtual `apply` method to parse props anymore. Instead, we use old-fashioned constructors.
* All fields of Props classes which represent props values were marked as `const` which make impossible to modify them after the objects were created (even if we have non-const value-of/pointer-to the whole Props object). Those fields are also `public` now.
* All custom handwritten getters were removed (because we don't need them anymore).
So, now we don't need all those custom getters which makes code much more compact, performant and codegen-friendly.
Reviewed By: fkgozali
Differential Revision: D7901245
fbshipit-source-id: 9f4b1fd2da64bf963b63215ed3bd74b9d3c58dd5
Summary:
LocalData might be used to communicate some infomation between `ShadowNode`s
and native component views.
We will use it soon to store (and transmit to mounting layer) prepared for rendering attributed text in Text component.
Reviewed By: mdvacca
Differential Revision: D7738582
fbshipit-source-id: 1ead23ffd105cce0b3d9aeb9fc1d0df47673be50
Summary:
The previous approach simply didn't work. :(
As you might notice, in previous implementation of ViewShadowNode::cloneAndReplaceChild we used `ViewShadowNode` class for cloning `childNode`, and this is incorrect becasue `childNode` might be instance of any class.
Reviewed By: fkgozali
Differential Revision: D7595016
fbshipit-source-id: 2215414926f2f7a2e2fd05ca2d065f10d6d32b74
Summary:
Apparently, there is no point to return a reference from this method because the struct (std::shared_ptr) is allocated on stack.
The test is also updated.
allow-large-files
Reviewed By: fkgozali
Differential Revision: D7557749
fbshipit-source-id: aa74146322c6d340256752586f05fc672024038e
Summary:
We have to call shallowSourceNode() in all cases of cloning which were not caused by UIManager instructions,
otherwise the diffing alogorith might produce incorrect mutation instructions.
Reviewed By: mdvacca
Differential Revision: D7503383
fbshipit-source-id: b33e5c39b7ba8cbd0f925fd29b3af379441a40a4