Summary:
@public
We don't need to maintain an order of this collection, so using `unordered_map` is more appropriate.
Reviewed By: mdvacca
Differential Revision: D8826946
fbshipit-source-id: f6890097cc5d6a1e06f6b2cfd1b7d68a388da461
Summary:
@public
We need this in case when we want to store several intances of the same class in the container.
Reviewed By: mdvacca
Differential Revision: D8814808
fbshipit-source-id: 78ab15d78cf3878d03bf0a45bc42b968d87435e7
Summary:
@public
In most cases callsite knows probable index of replacing child node, hence it makes sense to provide this info to `replaceChild` to illuminate O(n) search in most cases.
Reviewed By: mdvacca
Differential Revision: D8814809
fbshipit-source-id: 0edf82878a72260365e2757beb3886ad07c7464d
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:
@public
On Android, a color can be represented as 32 bits integer, so there is no need to instantiate complex color objects and then pass them as shared pointers. Hense instead of using shared_ptr, we use a simple wrapper class which provides a pointer-like interface.
Reviewed By: mdvacca
Differential Revision: D8742014
fbshipit-source-id: 14109b61fd84a34989538a15bc6fe4e2a8ce83a6
Summary:
@public
This approach is basically copying exising implementation that we have in RCTTextView (D5806097).
Changes in `AttributedString` is quite trivial.
Reviewed By: mdvacca
Differential Revision: D8740000
fbshipit-source-id: 276afdf93d777f7ccb99ca8ee5a18a880de2acbf
Summary:
@public
There is no reason to have it inside View; it deserves that.
Reviewed By: mdvacca
Differential Revision: D8757012
fbshipit-source-id: 881b54008b51614cd203ab97811494fa7c30e4ef
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
Summary:
Now, if `fromDynamic` is defined for some type, `fromDynamic` for `std::vector` of this type is also will be defined.
We need this for parsing `ImageSources` (a vector of `ImageSource`) type.
Reviewed By: fkgozali
Differential Revision: D8473508
fbshipit-source-id: d8dc8e3a3273f35b76c7132c553130762f768394
Summary: In case if it's just a number, it is treated as unified insets now.
Reviewed By: mdvacca
Differential Revision: D8473510
fbshipit-source-id: 1034377bc3e4abe55778c2f182360345419f00d5
Summary: This style/prop is called `position` (not `positionType`) in RN/JS API.
Reviewed By: mdvacca
Differential Revision: D8473509
fbshipit-source-id: f381189e05e6b618f3c74f1bc4610e737981b388
Summary: The matrix magic and parsing approach are mixins between current iOS and Android implementation.
Reviewed By: fkgozali
Differential Revision: D8344054
fbshipit-source-id: 524b48c5ab61959ce740373534d0d435eb37b647
Summary:
Just definition; we don't have an implementation on the native view layer yet.
And we don't have `transform` prop yet (because it's quite complex).
Reviewed By: fkgozali
Differential Revision: D8344058
fbshipit-source-id: 3b7b41480be8295cbc90b95ebe8562e52c6f81d7
Summary:
This is pretty straightforward implementation uses native `UISwitch`.
Suddenly we need Switch to test a bunch of other things.
Reviewed By: fkgozali
Differential Revision: D8344055
fbshipit-source-id: cfc51b8bc11198eb9d4d5e4745b96fb3a7f14de1
Summary: CornerInsets is something like EdgeInsets but about corners instead of edges.
Reviewed By: fkgozali
Differential Revision: D8344062
fbshipit-source-id: 9bf7a8696fba96e3124cb15e8e84093c1f4f8747
Summary:
On JS reload the FabricUIManager and EventDispatcher didn't get release due to a retain cycle. This breaks the cycle.
In addition, force release the Scheduler on reload so that the stale classes get cleaned up properly, avoiding crashes. Also the surface now remounts the content correctly
Reviewed By: shergin
Differential Revision: D8414916
fbshipit-source-id: 4b14031f29b3bc9987d7aa765dc0d930a7de2b1e
Summary: Calling the event emitters on the main thread seems to be problematic, so let's dispatch it via the JS thread. This requires some changes to make "eventTarget" single-use because otherwise the binding would need to synchronize the actual JS call with the act of releasing the target.
Reviewed By: shergin
Differential Revision: D8375291
fbshipit-source-id: bd2b42731176ae209f4a19c232309c163fb1c01b
Summary:
* numbers in JS are doubles in native land, since there's no notion of int or int64 in JS - so simply convert numbers to int instead of assuming it's int
* the parsing of Yoga props with `'...%'` string value has a bug: it should be copying the number instead of the `%`
Reviewed By: shergin
Differential Revision: D8370873
fbshipit-source-id: 44e9e3f0530c000c963e8e9ca66e8b0a48d80bcd
Summary:
I'm not totally sure what I'm doing so if this needs changes let me know.
Closes https://github.com/facebook/yoga/pull/775
Reviewed By: emilsjolander
Differential Revision: D8331892
Pulled By: passy
fbshipit-source-id: eb1023e666322d2472e4081fd4a4e72a7b43d049
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:
During transforming raw prop (`rawProps[<prop>]`) to typed props (`MyProps.<prop>`) we can face three different cases:
* `rawProps` collection has proper serialized value for the key. In this case, we have to set a new value of the typed prop converting value using `fromDynamic`.
* `rawProps` collection does not have value for the key. In this case, we have to copy a value from source prop (`sourceValue`).
* `rawProps` collection has `null` value for the key. This is the special case which means that the prop was removed from the particular component instance and we have to reset it to some *default* value (which is *not* the same as `sourceValue`). Now the default value of the `defaultValue` (sic!) argument is a default value of the type of the value (which may be different from logical default value).
We didn't handle the last case previously and this caused crashes (and unexpected behavior) because `fromDynamic` often cannot handle `null` value.
And yes, all this mean that we also have to update all `convertRawProp` call sites where logical default values are not equal to type-specific default values. This is a potential error-prone place, especially because now we have to specify logical default values in two places (in a prop declaration and in a parameterized constructor). And seems there is no way to avoid that without performance loss (because both of those places are basically constructors).
My hope is that codegen (where default values are also defined in JavaScript) will help with it eventually.
Reviewed By: fkgozali
Differential Revision: D8247652
fbshipit-source-id: 2cbe65f5f5cccd7a0d34aaa19e385aacebfe8cb1
Summary: The data model of Touch events and payload serialization. The implementation mimics W3C standard and current React Native implementation.
Reviewed By: fkgozali
Differential Revision: D8246711
fbshipit-source-id: 955b2068674f290d8bdb82da1ebfb796dd32971b
Summary: SUDDENLY, `-[UIFont systemFontOfSize:weight:]` returns incorrect result if `weight` is not exactly equal to any of built-in constants.
Reviewed By: fkgozali
Differential Revision: D8246712
fbshipit-source-id: 13d59cc8d66a4494437f28d791fd93fa83ebe6fb
Summary:
The current implementation of React Native uses `Size` as the underlying type of `textShadowOffset` which is clearly terribly wrong (especially because negative size values makes no sense). This mistake was borrowed from `NSShadow`, I believe.
I don't have time to fix this in every implementation of RN now, so let's use `Size` in Fabric as well.
Reviewed By: fkgozali
Differential Revision: D8246714
fbshipit-source-id: 1f0bf9b9dfa83802ef3faef2971fed5510494bfd
Summary:
`LayoutableShadowNode.cpp` includes `"LayoutableShadowNode.h"` as well as `<fabric/core/LayoutContext.h>`. In turn, `LayoutContext.h` then includes `<fabric/core/LayoutableShadowNode.h>`. `LayoutContext.h` doesn't actually require `LayoutableShadowNode.h`, but this unnecessary inclusion can cause duplicate definition errors if the two include paths don't map to exactly the same file. This patch removes the unnecessary include.
The CI's build system should cover the testing needed.
[INTERNAL] [MINOR] [fabric] - Remove an unnecessary include in fabric/core/layout.
Closes https://github.com/facebook/react-native/pull/19548
Differential Revision: D8313337
Pulled By: shergin
fbshipit-source-id: 2e01e29ff25131543d9a8601483c2e716c7437be
Summary:
This is the first attempt to implement some base part of event dispatching pipeline from end-to-end.
Even when it is working, all this is still incomplete and generally up in the air. We are still messing proper implementation of event queue, priority, and synchronization of react reconciliation process with event scheduling.
Reviewed By: fkgozali
Differential Revision: D8212271
fbshipit-source-id: 92f9427d14726441c70ffff294ac95eeb004152a
Summary:
In order to dispatch event, `EventHandlers` must also know react tag. So we have to store it inside.
We plan to illuminate this requirement (and `tag` from `EventHandlers`) eventually.
Reviewed By: fkgozali
Differential Revision: D8211685
fbshipit-source-id: 2064c0f4a7869cbf4d2c92d0349f4ee3998cb8f5
Summary:
Nothing actually changed besides type names... which actually helps me found an issue in FabricUIManager!
Now there is no a single `void *` in Fabric/C++ and JavaScript bindings. Yay!
Reviewed By: fkgozali
Differential Revision: D8191420
fbshipit-source-id: b1eb60b6bc34dd25ab200aab854ffbd7ccf5b15d
Summary:
It's maybe not so important/crucial, but this thing bothers me a lot.
We use raw opaque `EventTarget`, `InstanceHandle` and `EventHandler` pointers in application layer quite a lot and we don't have any kind of type-safety here. I believe all those opaque types should be represented as named scalar types which compiler at least can differentiate at compile time.
So I propose introducing named aliases for them which will point to particular empty `struct`s. This will allow us to tag types properly in all functions and methods and ensure that we pass right values as right arguments.
Again, they are *just aliases*, which are effectively still `void *`, no any additional logic or names are involved.
Unfortunately, those nice type names are already taken by `JSIFabricUIManager` local anonymous namespace (even if they are inside anonymous namespace we cannot use them https://stackoverflow.com/questions/3673353/anonymous-namespace-ambiguity). I think it's fair to rename them because... it's local. And we already use `Wrapper` suffix for them anyways.
Reviewed By: fkgozali
Differential Revision: D8181151
fbshipit-source-id: 9b55b43fb671a56b32a862ac54f78d528e1188ce
Summary: Now FabricUIManager is all you (or I) need to deliver an event.
Reviewed By: fkgozali
Differential Revision: D8086627
fbshipit-source-id: 70d783bee291f4c5d19650ac0768a5d2bd778961
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: A few more places to update to target iOS 9.0 (upgraded from 8.0)
Reviewed By: shergin
Differential Revision: D8108719
fbshipit-source-id: f17aa5e5aa34fdad57196202bf67a842735d4cdc
Summary: Note: Some features are not suported yet, e.g. event throttling.
Reviewed By: fkgozali
Differential Revision: D8082771
fbshipit-source-id: d60f6e9011283aeee7aff77dc9178e99f06deb5c
Summary: This also illustrates how we should use EventHandlers objects.
Reviewed By: fkgozali
Differential Revision: D8053357
fbshipit-source-id: cba084c8a871e40c7536720fce290c3467d33061
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:
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
Valentin Shergin
Taras Tsugrii
David Vacca
Scott Wolchok
Pritesh Nandgaonkar
Kevin Gozali
Sebastian Markbage
Vince Mi
Robert Sayre
Marc Horowitz
Héctor Ramos
Dan Zimmerman
Andres Suarez