Summary:
@public
Quite trivial. We had to have this from the day one.
We don't need cache invalidation policy because all subtree is immutable.
Reviewed By: mdvacca
Differential Revision: D8709973
fbshipit-source-id: bd7fcf0ae1dcb23894321cb5d16da18cb1ab788f
Summary:
@public
Everything is better with C++ templates.
In this cases templates allow us to remove additional parameters and casts on the callsite.
Reviewed By: mdvacca
Differential Revision: D8754523
fbshipit-source-id: 2340b2cd96ab0a60d54d9aa30dea3c072b951a8a
Summary:
@public
* In case of `ShadowTree` we just pass original old node as a `commit` method argument;
* In case of `ConcreteViewShadowNode` we just don't need that because diffing algorithm does not use that information anymore.
Reviewed By: mdvacca
Differential Revision: D8753906
fbshipit-source-id: b8555083c7e72e9b3c0f9a8065745946d4cf44c7
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: Holding floats by reference is unnecessary at best and may be detrimental to performance.
Reviewed By: davidaurelio
Differential Revision: D8826496
fbshipit-source-id: 2391f8aa26ebfbb440f6e4b7d57975be688f791c
Summary: I missed these two things: inline default ctor, getValue() should return a float.
Reviewed By: priteshrnandgaonkar
Differential Revision: D8826640
fbshipit-source-id: e6324dea0268ef276e6fa1722e72dffb5241e676
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: Just some convention/weird style things. `float` should be passed by value, weird use of ?: operator instead of ||.
Reviewed By: priteshrnandgaonkar
Differential Revision: D8804407
fbshipit-source-id: e0d67363ccde36ec5bccec7497ed0ffd364b3fcf
Summary: This linked list was never used, and YGNodeDeepClone was doing scary things to maintain it.
Reviewed By: davidaurelio
Differential Revision: D8792864
fbshipit-source-id: c578fabe65c837f0791aa9ac3e18f31d93691abd
Summary:
Fixes the improper `singleFlexChild` optimization. In the case when all the childs have `flex-grow:0 flex-grow:0` except one child with `flex-grow:1 flex-shrink:1`, then one can simply measure all the non-flexing children and then give the flexing child all the remaining space.
Also added a test case which reproduced the bug
Reviewed By: IanChilds
Differential Revision: D8782684
fbshipit-source-id: ffd4d35b6122f82111b987540efb23bd2a8da5a2
Summary:
@public
... and it's as efficient as it was before.
The previous version of the algorithm used `sourceNode` reference to know the previous state of the node to call the algorithm recursively.
That wasn't so good because of several reasons:
- It was fragile because we had two different sources of the truth of the "previous state of the tree": committed tree and source node pointer;
- We had to store weak pointers to source nodes inside cloned nodes. That is not free in terms of performance;
- The old approach introduced a constraint that all previously used and now reinserted nodes must be cloned to update source node (otherwise, the algorithm would regenerate instructions recreating already existing subtrees);
- That cloning required access to `isSealed` flag which is supposed to be a debug-only thing (that actually affects performance and must be compile-out for release builds).
The new approach compares nodes with same react tag and naturally cloning-artifacts resilient.
Yes, the new approach uses a map of inserted nodes, but the previous one already had it (otherwise there is no way to tell which nodes should be "deleted"). And anyway, this is a very little map that exists for a very little period of time.
Reviewed By: mdvacca
Differential Revision: D8709953
fbshipit-source-id: 027abb326cf45f00f7bb0bbd7c4e612578268c66
Summary: Revert the order of "remove mount items", to ensure views are removed from high index to low index.
Reviewed By: shergin
Differential Revision: D8742796
fbshipit-source-id: 6e04c39386d290bf3958ee83256d4fbe23e2c4ca
Summary: We were supposed to pass in proper eventEmitter, but passed in one with null eventTarget instead, causing assertion failures when dispatching event.
Reviewed By: sebmarkbage, shergin
Differential Revision: D8720793
fbshipit-source-id: 891f3b2a2c76a6dd3e40039623c6e86991aad50b
Summary:
@public
This compiles, but it works only on iOS for now.
Reviewed By: mdvacca
Differential Revision: D8655540
fbshipit-source-id: 7e9a73fadb317dd62298af6f347344ac4229a8a5
Summary:
@public
This compiles but this does not work.
To make it actually work we have to implement all missing functions in `Color.cpp` and co.
Reviewed By: fkgozali
Differential Revision: D8655537
fbshipit-source-id: 564fb7131445af81cf05407239dc6ba870cf6b83
Summary:
Removes the concept of instance handle. Instead we pass the event target
to createNode and don't pass it to subsequent clones.
The life time of the event target is managed by native (the event emitter).
It has to be released manually.
Reviewed By: shergin
Differential Revision: D8688330
fbshipit-source-id: e11b61f147ea9ca4dfb453fe07063ed06f24b7ac
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
Suddenly, it is not supported on Android.
Luckelly `folly:to<std::string>()` is as good as `std::to_string()`.
Reviewed By: mdvacca
Differential Revision: D8655538
fbshipit-source-id: 2b3b970f6a261253aaa6b22dba8338dc66b7195d
Summary:
This diff refactors the cloning mechanism for YogaNode used from Fabric UI renderer and RN iOS graphs.
Previously, we were cleaning the owner of the child's cloned node inside the C++ implementation of YogaNode. This was a mistake because this modified the last commited YogaTree, causing side effect in RN iOS graphs.
Reviewed By: shergin
Differential Revision: D8672627
fbshipit-source-id: c9902d00690e0361fd58aed84b506c42258bd995
Summary:
@public
This is follow up for D8601600 and D8247652 (the last one has detailed explanation of the problem).
From this commit I propose that we have to follow simple rule:
If some prop has a default value which differs from the default value of its type, we have to specify it as {<value>} in .h file and explicitly in .m file, for all other props the default value must not be specified explicitly (in .h files it must be specified as {}).
The reason is that we have to embrase those cases and establish behaviour: if we change the default value in .h file, it always means that we have to change the value in .cpp file too.
Reviewed By: fkgozali
Differential Revision: D8601776
fbshipit-source-id: 3379aace4e2d72febb2b942a3da1cb24decf54be
Summary:
@public
Otherwise, it can mess with implementation for `int`s and causes some errors where `float` implementation was requested but `int` was applied.
Reviewed By: mdvacca
Differential Revision: D8601752
fbshipit-source-id: cfe51b7785ff29ee4ad88f0f1cbfed335557d5ef
Summary:
Conditional `load`s are not allowed in Skylark. The logic
that belongs to different environments has to be part of environment
specific build defs and include as part of cell resolution or CI
configuration.
More context: https://buckbuild.com/concept/skylark.html
Differential Revision: D8604673
fbshipit-source-id: 385f2e155c4d80219e6ed3a2e0a82c909ebabb13
Summary: This is basic impl of <PerformanceLoggerFlag> component without any layout/mounting computation, just TTI.
Reviewed By: shergin, mdvacca
Differential Revision: D8598983
fbshipit-source-id: b938753d6396088735cbbeab26d69c9aaa45608e
Summary:
@public
It fixes a problem when some Views got disaper after they have non-zero opacity.
Reviewed By: mdvacca
Differential Revision: D8601600
fbshipit-source-id: 3da3ee591d4a685a8d7a56b15519d4d5cae4a031
Summary:
@public
The current Fabric architecture, in general, does not support "subscribing" for events, so all kinds of events are always delivered no matter have JavaScript components `on`-handlers for them or not.
At this point, we are not sure should it be this way or not. But we are sure that for some extremely noisy events (like onLayout) we have to make an exception right now (otherwise overall performance will suffer).
So, this diff implements that for `onLayout`.
Reviewed By: fkgozali
Differential Revision: D8597408
fbshipit-source-id: 6933b7cb96e24f0660bd7850b625ff27e3146a2b
Summary:
@public
We do preventing cloning in UIManager especially to add a layer to Shadow Node source chain,
so apparently there is no point illuminate that by calling `shallowSourceNode`.
Reviewed By: fkgozali
Differential Revision: D8585163
fbshipit-source-id: 3743edc30bf2183c420fd79ce1e59d68ceaa278b
Summary:
@public
We need this temporary for testing until we support them all.
Reviewed By: mdvacca
Differential Revision: D8552361
fbshipit-source-id: 25f48cebcf5a665a24b92803dd7738f947ca74b2
Summary:
@public
For now we only support trivial uniformed (all sides are equal) border rendering (which can be direclty mapped to CALayer features).
Support of the more complex and fancy borders is comming soon.
Reviewed By: mdvacca
Differential Revision: D8528923
fbshipit-source-id: 0883cdc2b855fc63d399e1a93010f259f0628f48
Summary:
@public
Another small but important piece of Accessibility Support.
Reviewed By: mdvacca
Differential Revision: D8528921
fbshipit-source-id: d4ba87bab702d76a90e9ddb751999193243cdc74
Summary: This diff cleans up the parent / owner references for children of ReactShadowNode / YogaNode during cloning. The reason of this behavior is to avoid retaining every generation of trees during cloning. This fixes a memory leak detected when running the ProgressBarExample.android.js in catalyst app
Reviewed By: fkgozali
Differential Revision: D8019894
fbshipit-source-id: b0d38f0c836ffec534f64fa1adbd7511ecf3473d
Summary:
@public
If some prop has `std::vector` type, it possible that on JS side we want to pass just one element of the array.
And in this case we sometimes drop array initialization (`[]`) part, so instead of passing `[{x:1, y:1}]` we pass `{x:1, y:1}`.
This diff adds support for that.
Reviewed By: mdvacca
Differential Revision: D8526572
fbshipit-source-id: 33d4369ac48cac3eb1c534f477d8259e76e0c547
Summary:
@public
This diff implements basics of cross-platform part of <Image> component.
Known issues:
- Events does not work yet.
- Some quite specific image source parameters (like custom http headers) are not supported yet.
Reviewed By: fkgozali
Differential Revision: D8526575
fbshipit-source-id: ecc97d9fda2b2e65bb1b079af057f8e176a161e5
Summary:
@public
ImageManager coordinates all work related to loading image bitmaps for <Image> component.
The particular iOS implementation uses RCTImageLoader from RCTImage module under the hood.
Reviewed By: fkgozali
Differential Revision: D8526571
fbshipit-source-id: a0d927972d30113eed6e0cd169fceee17610181d
Summary:
@public
After reading about move-semantic and rvalue refs I realized that we (I) definitely overuse `auto &&` (aka universal reference) construction. Even if this is harmless, does not look good and idiomatic.
Whenever I used that from a semantical point of view I always meant "I need an alias for this" which is actually "read-only reference" which is `const auto &`.
This is also fit good to our policy where "everything is const (immutable) by default".
Hence I change that to how it should be.
Reviewed By: fkgozali
Differential Revision: D8475637
fbshipit-source-id: 0a691ededa0e798db8ffa053bff0f400913ab7b8
Summary:
@public
`ContextContainer` is general purpose DI container for Fabric.
We need this to communicate some enviroment-specific and/or platform-specific modules down to cross-platform C++ code.
The first one will be ImageManager. Soon.
Reviewed By: fkgozali
Differential Revision: D8475636
fbshipit-source-id: 0afc65063f818d0bab736cd2c55c6fdd21b629ac
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:
@public
There are some race conditions between VM objects getting deallocated and the instanceHandle held by the eventEmitter can point to deallocated memory space, causing undefined behavior like a crash.
For now, keep a strong ref to the eventTarget inside EventEmitter to avoid that scenario. This is a temporary workaround.
Reviewed By: shergin
Differential Revision: D8576785
fbshipit-source-id: 87ef36f716270ceca906b32bb86e0046ceaca19e
Valentin Shergin
Taras Tsugrii
Scott Wolchok
Pritesh Nandgaonkar
David Vacca
Kevin Gozali
Sebastian Markbage