Summary: Support existing, backwards-compatible AndroidTextInput component for minimal support of TextInput on Android.
Reviewed By: shergin, mdvacca
Differential Revision: D17086758
fbshipit-source-id: 25726f22229e0d5dfe96eb36b386a5317601283d
Summary: Accessibility is essential but seems we don't have any use of AccessibleShadowNode in Fabric.
Reviewed By: sammy-SC
Differential Revision: D16139595
fbshipit-source-id: a6aec6d22c4a6050d7ee5e6b21ef4ad04d80ffce
Summary:
Previously we used `std::string` as a type behind all prop names (and name fragments). Even if `std::string` converted from `char const *` should be heavily optimized by STL and compiler, we still concatenate and copy those strings a lot. Switching to `char const *` allows avoiding tons of copying and inefficient equality checks.
Besides that, the future, more sophisticated optimization will rely on this.
Reviewed By: mdvacca
Differential Revision: D15511493
fbshipit-source-id: 9f509d18f0c737f7f77d4fea192d2ed1872e3731
Summary:
First of all, seems it's the right thing to do. Fabric C++ code is cross-platfrom and should run on *all* platforms including Windows, Linux, and Mac.
While we don't have a real *production* use cases where we need compilation for desktops, having CXX target is really handy for two reasons:
* It simplifies local test running process. Instead of going to `/fbandroid/` and executing something like `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:coreAndroid` (note the suffix). We can just do `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:core` everywhere and it works now out of the box. Running tests with "Apple" flavor never worked for me.
* It allows creating synthetic benchmark tests (using Google Benchmark) that can be used as a rough approximation of code micro-optimizations.
Reviewed By: JoshuaGross
Differential Revision: D15608678
fbshipit-source-id: d2449035685dbca6ab983480f5334ec4ac11cd35
Summary:
In order to remove the config pointer from nodes, we have to keep track of whether the node is using web defaults.
This information fits into one bit that we can place in padding (i.e. no extra memory needed).
This allows us to get rid of config usage withing `YGNode` with some exceptions:
- `iterChildrenAfterCloningIfNeeded` -- this function will simply receive the configuration, or the cloning callback.
- `setAndPropogateUseLegacyFlag` -- will be removed in D15316863
- in `YGNode::reset` -- will go away utomatically once we remove the config pointer
Reviewed By: SidharthGuglani
Differential Revision: D15391536
fbshipit-source-id: 0fa0d0805c6862bd741fe4a7d9b637ed534f56a4
Summary: `YogaStylableProps.yogaStyle` is designed to be consumed by Yoga only. Making it `protected` allows us to avoid confusion and misuse of this props.
Reviewed By: JoshuaGross
Differential Revision: D15296474
fbshipit-source-id: cf9e416afee99fb426d72765557b34d303a63dbe
Summary: This diff replaces usage of abort() with assert() when a prop-value is not found during parsing of prop values
Reviewed By: shergin
Differential Revision: D14563338
fbshipit-source-id: c799420e6b49df35e1d7ccdbd4bc4845067d33cc
Summary:
This diff changes the condition in `ViewShadowNode::isLayoutOnly()` removing checking for `onLayout` event listener.
We needed that before because the mechanism of emitting events was based on analyzing mutation instructures (we needed those to be generated for nodes with `onLayout`).
Recenly we changed that algorithm deeply integrating in layout infra, so we don't need this anymore.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15273491
fbshipit-source-id: 2d43f00d1b87369d5993fe5ba70c2de36b8ce0c5
Summary: Apparently, Yoga has a "quirks mode" and we have to enable that for Fabric. Which is probably a mistake that we have to make one more time.
Reviewed By: davidaurelio
Differential Revision: D15267852
fbshipit-source-id: 88a910fafc9ff64fb19376f4b74a2f2fd5827eba
Summary: I have noticed that `backfaceVisibility` example crashes (because actual value is a string/enum, not a boolean), so I fixed it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219261
fbshipit-source-id: 27f76cd10903794d597adacb9da7300a42813f8e
Summary:
`LayoutableShadowNode::getTransform` returns a transform object that represents transformations that will/should
be applied on top of regular layout metrics by mounting layer.
Reviewed By: mdvacca
Differential Revision: D15219262
fbshipit-source-id: e7aeb85b5f7e2fce3f8faf9dfcaee5dae3217d36
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:
Different frameworks use different kinds of floats, optional floats, and floats with assigned unit names. All those approaches use different ways to represent undefined and empty values. To deal with it we need to have some helper functions.
So, this diff changes some ways that we convert some corner values (like NaN and empty value). That change is motivated by recent personal discoveries in this field that shifted my vision on that. E.g. ComponentKit does not use `CGFloatMax` value as `Infinite` value. UIKit is also (surprisingly to me) okay with using `Infitite` instead of `CGFloatMax`. And, in general, seems using really conceptually appropriate values (instead of UIKit-inspired ones) it's the right thing to do.
Reviewed By: mdvacca
Differential Revision: D15155189
fbshipit-source-id: 33e15141f1ca3efb400a7160811224335de34ba1
Summary:
We don't need to have those constants because this functionality is available in STL via `std::numeric_limits<YourParticularFloatType>::infinity()` (or `::min()` and `::max()`).
At the same time usage of `kFloatMax` was replaced with `Infinity` (which is a different value). Using `max` instead of `Infinity` was an attempt to mimic iOS/UIKit model where `Infinity` and `NaN` values usually are not being used. However, now this does not seem like a good idea. This concept is not used anywhere else (even in CK which is totally incompatible with it) and de-facto in RN we use it only in few places. So, let's use Infinity in places where it's logically appropriate.
Reviewed By: mdvacca
Differential Revision: D15155191
fbshipit-source-id: 4d24350c7540cec074a8b040d7c13f257aa812e7
Summary:
@public
Adds `YGStyle::ValueRepr` to make code depending on the actual type easier to write.
So far, we have treated `yoga::detail::CompactValue` as an implementation detail, and that’s what it’s supposed to stay.
React Native Fabric has one value conversion overload that depends on that type, though, and used `decltype(YGStyle{}.margin()[0])` until now.
That’s problematic for two reasons:
- we want to constrain the parameter of `operator[](...)` to enum types, making the `0` unsuitable
- we want to return the non-const overload of the operator to return a custom `Ref` type, which is not the type needed by Fabric.
Making the storage type explicit allows to write more forward-compatible code.
Reviewed By: SidharthGuglani
Differential Revision: D15078960
fbshipit-source-id: 932c27ef2f2cdc6ce965b79894268170f0ccdce5
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
UAs must adjust border radius values to fit a content box:
>>> Corner curves must not overlap: When the sum of any two adjacent border radii exceeds the size of the border box, UAs must proportionally reduce the used values of all border radii until none of them overlap.
This diff implements that.
Reviewed By: mdvacca
Differential Revision: D15028325
fbshipit-source-id: 368232ffa2fa0409d13759bbbe7fe10f8474c400
Summary:
We will use it inside `core` module, so we have to decouple it from `view`.
As part of this, I added some comments, changed `const Float &` to just `Float` and put the implementation into `.cpp` file.
Reviewed By: mdvacca
Differential Revision: D14593952
fbshipit-source-id: 80f7746f4fc5b95febc8df9f5a9c0386a6425c88
Summary: This diff replaces usage of abort() with LOG(FATAL) when a prop-value is not found during parsing of prop values
Reviewed By: fkgozali
Differential Revision: D14591210
fbshipit-source-id: 4a8484ea6bdfec5534122ded43cc24ef80c13c1d
Summary: This diff replaces usage of abort() with LOG(FATAL) when a prop-value is not found during parsing of prop values
Reviewed By: sahrens
Differential Revision: D14570713
fbshipit-source-id: 57b0f993ba264a4949baf4022d807c55cdfe03b1
Summary: Conceptually, this assert is correct, however, sometimes a new node got allocated by same address as old parent node (which does not exist already) which makes the assert fires.
Reviewed By: mdvacca
Differential Revision: D14533070
fbshipit-source-id: 3fcc71c25e7d724180dc85aaf2457227d22ddba0
Summary:
With recent changes, simple cloning a component does not mean that underlying Yoga node will be dirtied. Autodirtying is only performed if the child nodes were dirtied and/or if the YGStyles were changed.
That's not the case for Text component which does not have direct layotable children, so we have to call `dirtyLayout` explicitly.
Reviewed By: JoshuaGross
Differential Revision: D14508277
fbshipit-source-id: 2c52d7d40da963a976c7d28a13781cc1755ef591
Summary: More `assert`s and `ensureUnsealed` calls were added to YogaLayoutableShadowNode for simpler debugging and early failing.
Reviewed By: JoshuaGross
Differential Revision: D14496936
fbshipit-source-id: 898c6a0665aeac5d0b1995bd53046f58cec37007
Summary:
If the `HasNewLayout` flag is `false`, we should not copy the data from YGStyle/YGLayout to ShadowNode because the node can be already sealed and because it's unnecessary. Previously we workaround this case with a special check in `setLayoutMetrics` method, but that can be unreliable because of some side-effects related to pixel rounding and comparing floats.
The new approach is much more robust and explicit.
Reviewed By: JoshuaGross
Differential Revision: D14496939
fbshipit-source-id: deddb14d2206c5bd3f22154d0ea682e3c5888901
Summary: These default implementations are never being used. Removing them allowing to ensure that flags inside YGNode have same values as flags in YogaLayoutableShadowNode. That also saves a couple of bytes in size of ShadowNode.
Reviewed By: JoshuaGross
Differential Revision: D14496938
fbshipit-source-id: c43f9c8a2eec054f728ff54a6573668eccda55fb
Summary: That diff fixes an obvious bug that prevents internal data of LayoutableShadowNode being cloned during cloning of YogaLayoutableShadowNode.
Reviewed By: JoshuaGross
Differential Revision: D14472753
fbshipit-source-id: d07be3bf36708690dfe10de7898e2b48648aa0f4
Summary: In addition to the previous change, now we handle a situation where some node receives a new set of children and all those children have the same styles. (See the previous diff for more details.)
Reviewed By: JoshuaGross
Differential Revision: D14472754
fbshipit-source-id: 16411036e14f18e730e064e33948440b05ff51c8
Summary:
After the change, YogaLayoutableShadowNode will preserve dirty flag (being false) in cases where:
* a node was cloned with same children;
* changes in props don't affect layout.
Motivation:
In Fabric we always were aggressive about dirting yoga nodes: when we clone the node, we always dirty underlying Yoga node. I think that was the case because we don't deeply understand how the system works and we always had more severe problems to fix. Now, we faced an issue that forces us to think about that problem carefully (more about that later).
(I don't expect that will improve TTI performance, but that's possible if we do a lot of changes in the hierarchy during initial load process.)
I see two main use cases where we have to be smart about dirtied yoga nodes:
Case 1. Native local commits which do *not* modify yoga styles.E.g. in a case where ScrollView updates the internal state (which has offset info) really really frequently. (It will be implemented later.) That `contentOffset` info does not or might not affect layout, so we should not pay for this.
Case 2. Legit React commits which do *not* modify yoga styles. E.g. in a case where only the background color of some view changes, we don't need to relayout anything. Unfortunately, we do this in Fabric because of two major reasons:
* We don't make a difference between any changes in Props.
* React constructs new children of cloned node iteratively, calling `appendChild`. That makes implementing optimization really challenging because we don't know when the process ends. And when it ends we have very few pieces of information about how the state looked before.
This diff stack will handle the problems of the first kind. The main motivation is: we want to have state updates to be as lean as possible.
Reviewed By: JoshuaGross
Differential Revision: D14472752
fbshipit-source-id: 68374f60cb07de9ab65bf1f6d94c828985359fa5
Summary: Several things need to ironed out: 1) LocalState in Fabric C++, 2) setting dimensions of BottomSheet component to 0,0 for parent.
Reviewed By: shergin
Differential Revision: D14426167
fbshipit-source-id: 45a90a7971c87672872108a9e360926b4a6095f0
Summary: The hope is that it will remove many unnececery allocations improving overal perfromance.
Reviewed By: mdvacca
Differential Revision: D14249198
fbshipit-source-id: f0442b3919ccead0582a3190dea0e33d517d85f6
Summary: It can save us a couple of ms, hopefully.
Reviewed By: mdvacca
Differential Revision: D14249196
fbshipit-source-id: b5911bcd8b49be66de7b9d2da660df38ef7cc8cd
Summary: That should reduce the size of `ShadowNode`, make an instantiation of shadowNode a bit faster, and make `clone` operation a bit faster because simple dynamic dispatch is faster than std::function invocation. It also should help a bit with code size.
Reviewed By: mdvacca
Differential Revision: D14249200
fbshipit-source-id: c1332b139d27becebf15cd894475507b5fd0eb9f
Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Summary:
The ConcreteViewShadowNode was changed to be independend of actual amount of template arguments of ConcreteShadowNode.
We will use it soon.
Reviewed By: JoshuaGross
Differential Revision: D14187761
fbshipit-source-id: b4c8051e2ae3803932713b0c255492466e80d3bd
Joshua Gross
Min ho Kim
Valentin Shergin
Kevin Gozali
David Aurelio
David Vacca
Estevão Lucas
Yuan Du
empyrical
Yedidya Feldblum