Summary:
This is the first diff in the journey of removing `enable_shared_from_this` from `ShadowNode` class.
In general, using `enable_shared_from_this` is fine, it's a normal standard feature and there is nothing wrong with that... besides the fact that using this thing is usually an indication of overall poor design.
In Fabric, we don't really have a good reason for that, I think in all cases it can be avoided, so I think we should remove that.
Removing that is also code-size and perf win.
This particular diff changes the signature of `RootShadowNode::clone()` which allows removing the necessity of usage `.shared_from_this()` from callsites.
The rest changes are purely cosmetical.
Changelog: [Internal] Small Fabric-specific optimization.
Reviewed By: sammy-SC
Differential Revision: D17973958
fbshipit-source-id: 5539ceff9d11b4281a6ebe8d80e90d6bd90e44d8
Summary:
Previously we computed the list of nodes that need to be notified about layout changes using a list of mutation instructions. That was fine, but that's not really compatible with some other changes that I plan to make, so I decided to change it (make it better).
Besides the better design (debatable; fewer dependencies to unrelated moving pieces), here is why I believe the new way is more performant:
* The new approach has no `dynamic_casts`, whereas the previous has tons of them (two per a mutation). If a `dynamic_cast` takes 10 ns, for 500 nodes it can take up to 5ms only for casts. (Non-scientific assumption.)
* After removing dependency to mutation instruction, we can enable flattening for views which have `onLayout` event.
Reviewed By: mdvacca
Differential Revision: D15110725
fbshipit-source-id: 31a657ccfd02441734ad1d71a833653223163289
Summary:
Removing additional complexity from ShadowTree should help with maintainability. Now, this class is "tricky", but short at least.
With new `commit` API, it's much more simple and expected this way.
Reviewed By: sahrens
Differential Revision: D13615365
fbshipit-source-id: 1fe851c1a2d3bdc7ac2f4a570cf0170eae3c4c67
Summary: Now it's parts of RootShadowNode and Scheduler.
Reviewed By: sahrens
Differential Revision: D13615364
fbshipit-source-id: 13dbea1e69ef51b2679101915c01c6be7e15d859
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:
All code styles are terribly ugly. We have the only choise - choise something and embrace it.
This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
Reviewed By: mdvacca
Differential Revision: D10218598
fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
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
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
There is no reason to have it inside View; it deserves that.
Reviewed By: mdvacca
Differential Revision: D8757012
fbshipit-source-id: 881b54008b51614cd203ab97811494fa7c30e4ef
Valentin Shergin
Andres Suarez
Héctor Ramos