Summary:
@public
Non-null owner pointer in Yoga node indicates that this node is already being used by some other subtree, so it must be cloned in case of possible (re)layout.
Theoretically, this node must/can be cloned by Yoga right before applying a new layout to this node, but Yoga has a special optimization that uses that fact that Yoga always cloning *all* children of a particular node altogether. This is not true for React; to meet React and Yoga worlds we double check the owner pointer in `addChild` and clone node preliminary if needed.
See also the previous diff for more context.
Reviewed By: mdvacca
Differential Revision: D8709952
fbshipit-source-id: 84ef0faa0f1d9cc9a8136b550cf325bc20508d53
Summary:
It's wasteful to do it by value. I'm fairly sure this is
safe, especially because
fbd332dee8 (diff-ade2a4bbd6582e2898cbd9e0fa142ab5R215)
shows that we did access by reference before.
Reviewed By: priteshrnandgaonkar, davidaurelio
Differential Revision: D8822697
fbshipit-source-id: 791bcf0fa37453f67795af727c85c8adce3b0f69
Summary:
@public
Most of them are legit issues which should not be compilable anyways (but Clang tolerates thems).
Reviewed By: mdvacca
Differential Revision: D8655539
fbshipit-source-id: 645729fb9d6a120ce1ab2b07542abcdacd72320d
Summary:
@public
This diff changes how we store and manage Yoga Config in layoutable shadow nodes.
Previously we have `shared_ptr` to single shared yoga config (one to many relationships); now we initiate and store yoga config with yoga node (one to one relationship).
Cons:
- Less memory efficient.
Pros:
- Much more flexible model. Configuration can be tweaked on a per-node basis.
- More performant. Dealing with `shared_ptr` is expensive because of atomic ref-counter. (This is not really applicable for the previous approach but would be applicable for any alternate approach where we want to have more granular control of the configuration.) Data locality is also great in the new model which should positively impact performance.
- Simplicity. Any alternate approach where we manage sets of nodes which share the same configuration is going to be quite complex.
Reviewed By: fkgozali
Differential Revision: D8475638
fbshipit-source-id: 5d73116718ced8e4b2d31d857bb9aac69eb69f2b
Summary:
@public
... and we initalize this in Surface.
We need this for requesting images with proper size/pixel-density, setup proper parameters for rasterizing CALayer's and rounding layout metric values.
Then we have to figure out how to wire this up with YGConfig.
Reviewed By: fkgozali
Differential Revision: D8475639
fbshipit-source-id: cec7af581b94efb4595dcf3f232252ce87a1fde3
Summary:
YogaLayoutableShadowNode::yogaNodeCloneCallbackConnector is a hot path.
Previous implementation did not use provided `childIndex` which is correct for most cases.
See comments in code for more details.
Reviewed By: fkgozali
Differential Revision: D8070120
fbshipit-source-id: d1a6abe82688387752b66a57b13dc356abb22c96
Summary:
Given that fact that life-time of YGNode and ShadowNode objects must be idential and that we always allocate ShadowNode on heap,
we can embed YGNode object right inside ShadowNode object and use pointer to it safely.
That allows us to save additional memory allocation for every single layoutable shadow node! Whoo-hoo!
Reviewed By: fkgozali
Differential Revision: D8070121
fbshipit-source-id: 6eefbca1b7ac0a8aad235513b4c4899d414835f2
Summary:
I recently realized (Thanks David!) that we should not use `shared_ptr` for storing YGNode*
because ShadowNode does not share ownership of the Yoga node with anybody.
So the lifecycle of shadow node and yoga node must be synchronized (this is already the case but changing to unique_ptr makes this explicit and a bit more performant).
Reviewed By: fkgozali
Differential Revision: D8030417
fbshipit-source-id: c7f85ea309598d2a5ebfed55b1d182d3fe1336ae
Summary:
A few fixes:
* missing include: folly/Optional.h
* switch folly::Optional's `has_value()` to `hasValue()` for now until folly is upgraded to newer version
* fix up import for RCTTextAttributes.h
* fix up includes for "conversions.h" to use namespaced includes
Reviewed By: mmmulani
Differential Revision: D8021149
fbshipit-source-id: d3955986d3ab6b1d9b61ac1e385767893ce57e5e
Summary: Conceptually, it always must be node owner's responsibility, but for the root node, we have to make an exception because there is no another parent node and there is no another component which has access to YogaNode.
Reviewed By: fkgozali
Differential Revision: D7958251
fbshipit-source-id: 0bdaea87adbd323c758bc3c28f325be615aa90f3
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `view` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958242
fbshipit-source-id: 10199d1fbb43329de93604aa383c884f5cc64dc5
Summary: This is continue of the work started in D7797561.
Reviewed By: fkgozali
Differential Revision: D7901244
fbshipit-source-id: 2f7a5cd9fa8c0079787e26e19c7c6c4255e54b42
Summary:
This a natiral continue of previous/ongoing work towards modernizing props pipeline.
Less defines, less code, more obvious code.
Reviewed By: fkgozali
Differential Revision: D7901246
fbshipit-source-id: 3387b6d13e21e6ec48a38c9e3708762dfe536105
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:
Apparently, we don't need this functionality in Fabric because we compute mutation instactions during diffing anyways.
But we still need (will need) `LayoutContext` for sure.
Reviewed By: mdvacca
Differential Revision: D7857045
fbshipit-source-id: 4be2744d9abea473ead847f35f698104f94af33d
Summary:
YogaLayoutableShadowNode::enableMeasurement() connects Yoga's measuring API and Fabric measuring API.
`enableMeasurement` should be called for leaf Yoga nodes with custom content which should be measured manually during layout.
Reviewed By: mdvacca
Differential Revision: D7738574
fbshipit-source-id: ffe883905c4809290d4d973ad29dc5f0e1ec7573
Summary:
It's more useful and consistent now because:
- We print compound layout metrics from the correct storage (not from Yoga nodes);
- It works fro any kind of layout now (but we still have just one);
- It's much clear and straight-forward.
Reviewed By: fkgozali
Differential Revision: D7607422
fbshipit-source-id: 4c3cd2848e785a7f77c7f591e376d00c7c09ade9
Summary:
The previous name conflicts with the method with same (but with different semantic) name in `ShadowNode` class.
That was bad idea to use same name especially because the different semantic.
Reviewed By: fkgozali
Differential Revision: D7554549
fbshipit-source-id: 0bccbaacd0812f8a26592b2008f15ddb5bc34ebc
Summary:
`enum class` types do not provide default conversion to integers and reguire use typename before value names.
This must prevent bugs like the previous one where we used `Undefined` as a number value.
Reviewed By: fkgozali
Differential Revision: D7554548
fbshipit-source-id: b19379aae48c9aebe03043e08cf3acc712da3cb8
Summary: `Undefined` is actually equal `0` (becasuse it is `LayoutDirection::Undefined`), whereas `kFloatUndefined` is a magic huge number.
Reviewed By: fkgozali
Differential Revision: D7554550
fbshipit-source-id: 3ea37f0b8b6a59b4b0e00d205b75cd7252247d03
Summary:
YogaLayoutableShadowNode::yogaNodeCloneCallbackConnector recently was disabled because of change in Yoga (D7339832).
This diff brings is back.
Reviewed By: mdvacca
Differential Revision: D7526417
fbshipit-source-id: 5369d641bf1e118132cf742d2d243bf426c0ffdb
Summary: We have to call `ensureunSealed()` only if the node was changed.
Reviewed By: mdvacca
Differential Revision: D7503388
fbshipit-source-id: a3d07d50fa983ef93c14fa771711fa783fdf4c12
Summary:
Motivation:
* We never should call `markDirtyAndPropogate()` during tree construction/mutation because it might affect trees in different thread/dimentions;
* In Fabric we basically always have to dirty nodes ourselves manually duting tree construction;
* In Fabric we don't have "scoped/limited" tree mutations which require recursive dirtying; any mutation is creation of the new tree instance;
* Default value of the `isDirty` flag is "false", so we have to change this right after creation of Yoga node (and after cloning).
Reviewed By: mdvacca
Differential Revision: D7467797
fbshipit-source-id: 2c9144271dceea6ba2b95173209b99b5d86fbd87
Summary:
The modern Concurent Yoga's concept is:
We have to set parent/owner reference as part of `appendChild` process only if the current reference to parent/owner is `null`.
The motivation:
* Null-parent indicates that this node was not attached to anything yet;
* So, in this case there is no any concurrent memory access because we always create and (first time) attach the node on same thread;
* Simmetrical parent-child relationship indicates that we don't need to (re)clone assosiated ShadowNode (nor Yoga node).
Reviewed By: mdvacca
Differential Revision: D7467791
fbshipit-source-id: 9a7f517380fde3bb00272de18fd5dc13edb52071
Summary: Any change must be propagate upwards.
Reviewed By: mdvacca
Differential Revision: D7389058
fbshipit-source-id: 09c74640d0e9607d2e17bdd31d7ce69df8565f72
Summary: We replace yogaNode with newly creaded (by Yoga) one. So, we have to set up context.
Reviewed By: mdvacca
Differential Revision: D7376345
fbshipit-source-id: 7926a10e3f057fc385e7731c354827aeb8245760
Summary: Trivial. We don't use it, and it shouldn't be exist by desing.
Reviewed By: mdvacca
Differential Revision: D7376351
fbshipit-source-id: 22f03af2b3596c274a22bab1fab6d8af854a7374
Summary: `LTR` is actually a default value for `direction` here, because an `inherit` value makes no sense for YGLayout (because it's *computed* value by definition).
Reviewed By: fkgozali
Differential Revision: D7330335
fbshipit-source-id: b3c7736c104689f2296e150f0cf57d622483d537
Valentin Shergin
Scott Wolchok
Kevin Gozali
Pritesh Nandgaonkar
David Vacca