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
Kevin Gozali
Pritesh Nandgaonkar
David Vacca