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
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, 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:
The new interface of ComponentDescriptor makes ShadowNode creation/cloning process a bit more explicit:
Now customers (UIManager) must prepare Props object explicitly before creation or cloning.
Besides general clarity, we need this to prepare for a new virtual `ShadowNode::clone()` method which will serve "virtual constructor" role,
redirecting execution to concrete ComponentDescriptor instance.
Actually, the whole purpose of concrete ComponentDescriptor instance is serve "virtual constructor" role (and all this code should be "templated").
Reviewed By: mdvacca
Differential Revision: D7591714
fbshipit-source-id: 8793b3ef70ed7ae113efb36ad1eee20573360dc8
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
Valentin Shergin
Kevin Gozali