Summary:
Changelog: [Internal]
View gets flattened even though it has `display: none` and therefore it and its children do not get hidden.
Reviewed By: shergin, mdvacca
Differential Revision: D21929033
fbshipit-source-id: 994a79fb64fbe66273a70218ebe8056d92cd3cd4
Summary:
This diff adds support elevation prop in Fabric core, additionally it adds this prop as non collapsable on the view flattening algorithm
changelog: [Internal] internal change in fabric to support elevation prop
Reviewed By: JoshuaGross
Differential Revision: D21896465
fbshipit-source-id: e0854acc0b2ac30eaf3f82d615aab1cf378cc530
Summary:
Changelog: [Internal]
View with `ShadowColor` was getting flattened and therefore views didn't have shadow property set.
This is fixed by promoting ShadowColor so in case it is set, it forms stacking context.
Reviewed By: shergin
Differential Revision: D20792201
fbshipit-source-id: 1033ac00e32047ffbb14e61b7c26348c578d132d
Summary:
Changelog: [Internal]
`orderIndex_` was only being assigned for `ViewShadowNode`, not for other `ShadowNodes` that are later represented on the screen.
Reviewed By: shergin
Differential Revision: D20746477
fbshipit-source-id: c04c2cfea14b9141d22bc3d9e9bb4c0c59925754
Summary:
Now, having `orderIndex` feature in the core, we can use it for implementing `zIndex` feature. All we need to do is just to assign this `zIndex` value to `orderIndex`.
Then we will use this to remove some platform-specific code that implements `zIndex` on the mounting layer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20432155
fbshipit-source-id: b4d62b63006f45899de38e1f40b1dfbe69550ada
Summary:
It's not clear why exactly but seems in some cases, for some views the hierarchical relationship between views is required (when it should not be conceptually). Turning this feature off for Android for now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20292833
fbshipit-source-id: 1aab8468cedeb5c1440a95944be7eca3216e0db0
Summary: Now, following the previous diff, we remove `LayoutableShadowNode::isLayoutOnly()` and change the view flattening algorithm to rely on two new traits. See the previous diff to learn more about how it works.
Reviewed By: sammy-SC
Differential Revision: D20212252
fbshipit-source-id: 87a07e8bb17b2e66e5703f107dc35ca7a8e49634
Summary:
This diff introduces two new `ShadowNodeTrait`s that we will use in the future in the new (slightly tweaked) view-flattening algorithm. (Note: this diff does not enable the new flattening, it's just preparation.)
The idea is that we split the notion of `isLayoutOnlyView` into two traits:
* `FormsView`: `ShadowNode`s with this trait must be represented as `ShadowView`s. Normal "visible" ShadowNodes will have this trait, but "layout only views" in old nomenclature will not.
* `FormsStackingContext`: `ShadowNode`s with this thread not only must be represented as `ShadowView`s but also have to form a "stacking context" which means that their children must be mounted as `ShadowView`'s children.
Our implementation does not exactly follow W3C spec in terms of sets of props that create the stacking context (because of historical reasons and mobile specifics) but ideologically it's the same. We start from the very conservative implementation where only views with background-color and borders do not form stacking context and then we probably extend that to more props.
Most importantly for us now, we will enforce the absence of ``FormsStackingContext` for `ParagraphShadowNode` and the presence of `FormsView` for `TextShadowNode` on Android where it's essential for mounting layer.
Read more about stacking context here: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20212253
fbshipit-source-id: 0fbaee214ce2c5886cb0232843a2a3c7bb20655d
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 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:
@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: This diff enables view flattening for Android when using Fabric.
Reviewed By: shergin
Differential Revision: D10254678
fbshipit-source-id: cc7acaa38a6d01e112ba0e8a92db61cdeefbffee
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 implements `onLayoutOnly` for regular bare <View> component (*not* for its descendants!) After this view flattening is actually starting working for all platforms.
Reviewed By: mdvacca
Differential Revision: D9511001
fbshipit-source-id: 3562dd1b7570a064150f100cc2e1bc4220b81290
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
Jiayan Zhuang
Samuel Susla
David Vacca
Valentin Shergin
generatedunixname89002005287564
Andres Suarez
David Aurelio
Spencer Ahrens
Héctor Ramos