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
Summary: <Image> support isn't there, so fallback to <View> instead of crashing.
Reviewed By: shergin
Differential Revision: D8086403
fbshipit-source-id: 16d7fd8023f93cbe25f2bc0f7d0a03e32cd402ce
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: Each app has its own set of components to support, so this mechanism allows each of them to customize the set. Core library only provides the signature (.h file) without any impl.
Reviewed By: shergin
Differential Revision: D8065360
fbshipit-source-id: c123397afda678e84f1d1fa41a6393f25b2c15e1
Summary:
Now ConcreteComponentDescriptor can infer `ComponentName` from `ShadowNodeT` automatically,
so in the most cases we even don't need to create a subclass of that.
Reviewed By: fkgozali
Differential Revision: D8016965
fbshipit-source-id: d910597093c9f4c9f32ca06cb3ef1b12538b9543
Summary: We don't use them at all; moreover they complicate adding/changing signatures of those methods (because arguments with defaults must be grouped at the end and some arguments cannot have defaults).
Reviewed By: fkgozali
Differential Revision: D7981456
fbshipit-source-id: d7dd098e83630d1ab3342d2ca52ade9c4e27b2c3
Summary: Note: not all scrollview props and features (especially event listeners and imperative calls) are supported yet.
Reviewed By: fkgozali
Differential Revision: D7961868
fbshipit-source-id: 5277674fe976e089fd963066f78e705ad846d78d
Summary:
All the props of a scrollview, and local data.
LocalData part is probably the most interesting: with it we precompute content size which we use inside native scrollview. Previously we rely on some assumptions like "ScrollView must have only one subview" instead, and that was not so efficient and straight-forward.
Reviewed By: fkgozali
Differential Revision: D7961869
fbshipit-source-id: fa070b8423a3e7739aeb62220e51213683e1a223
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: We will need this for several components, first of all for ScrollView.
Reviewed By: fkgozali
Differential Revision: D7958246
fbshipit-source-id: 364b939abe8f0734376448149bbdc735abd00189
Summary: Trivial. We will need them soon at least for ScrollView.
Reviewed By: fkgozali
Differential Revision: D7958244
fbshipit-source-id: ce92c6e6181181ac17d817292af18ffa46a4d975
Summary: Apparently, `calculateMutationInstructions` must also produce mutation instructions for root node as well. To make it possible we have to change the signature of the function and weak some restrictions in TreeMutationInstruction.
Reviewed By: fkgozali
Differential Revision: D7958248
fbshipit-source-id: 4109a6bce3a77f7eb89157201fd0e80f98487dbd
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
Kevin Gozali
Valentin Shergin
Robert Sayre
Marc Horowitz
Héctor Ramos
Dan Zimmerman
Andres Suarez
Sebastian Markbage
Dmitry Zakharov
Taras Tsugrii