Summary:
1. Split out the prop interpolation function out of the View ComponentDescriptor, into an inline'd function that can be used elsewhere.
2. Call it from View and from Paragraph component descriptors.
This causes animations including Text to look normal on iOS.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21675804
fbshipit-source-id: c34a317749fd6c108aef072d47f3dcb14ce8aa5c
Summary:
1. Split out the prop interpolation function out of the View ComponentDescriptor, into an inline'd function that can be used elsewhere.
2. Call it from View and from Paragraph component descriptors.
This causes animations including Text to look normal on iOS.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21635473
fbshipit-source-id: 470f43fd24a6e80d8696ee2f2a09d9e693b7f280
Summary:
Move and create an empty rule that redirects as well, to handle //arvr rules
Need to do this way, since ovrsource sync rules are in different repo.
allow_many_files
allow-large-files
Steps:
- [X] Move glog from xplat/third-party to /third-party
- [ ] Update references in ovrsource to translate to //third-party instead of //xplat/third-party
- [ ] Get rid of temporary rule
- [ ] Update fbsource/third-party/glog to 0.3.5 (what we have in ovrsource)
Changelog: [Internal] Update reference for glog from xplat/third-party to /third-party.
Reviewed By: yfeldblum
Differential Revision: D21363584
fbshipit-source-id: c1ffe2dd615077170b03d98dcfb77121537793c9
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885163
fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af
Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: scottrice
Differential Revision: D20495655
fbshipit-source-id: a57b72f694c533e2e16dffe74eccb8fdec1f55f5
Summary:
Changelog: [internal]
layoutDirectionPass down layoutDirection from `RCTSurfacePresenter` down to `YogaLayutableShadowNode`.
In `ParagraphShadowNode`, we propagate layoutDirection from yoga node to `TextAttributes.layoutDirection`.
Reviewed By: shergin
Differential Revision: D20420041
fbshipit-source-id: 86e01d31ea9415acb8579c44c470cac870ec1b8f
Summary:
This fixes a bug in Android TextInlineViews that was reproducible in ActivityLog screen, see T63438920
Since Text are virtual nodes it is not necessary for these kind of views to stack views during diffing.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D20448085
fbshipit-source-id: 2d852975493bf6bcc7840c80c5de5cb5f7890303
Summary:
We need that to move all `TextShadowNode`s to the end of the list of nodes to make view indexes work for nodes that actually have views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20396717
fbshipit-source-id: efbef47ef89ab37e83e020c029c39e1a62727fda
Summary:
The new name is get_preprocessor_flags_for_build_mode.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D20351718
fbshipit-source-id: 67628ce81e7244f0f72af2d00d92842a649ff619
Summary:
This diff changes API we use to measure text. Previously, a platform-specific measure infra returned just the size of the text, now it returns the size and an array of frames that describe where attachments are placed.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268041
fbshipit-source-id: 7c065607b6af18a36318db0aab24dad0f171d33a
Summary:
`ParagraphShadowNode::Content` describes all nested content of a `Paragraph` component as a single entity allowing to reason about that as a thing that holds an invariant. Now we can store that as a single thing, copy, pass to functions, build on top of that and etc.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC, mdvacca
Differential Revision: D20268043
fbshipit-source-id: e976588ad76615259c72bc21f9ad8d923f2f3b9f
Summary:
`BaseTextShadowNode::getAttributedString()` was replaced with simular method `BaseTextShadowNode::buildAttributedString()` which does same work with following differences:
* Besides returning `AttributedString`, it retures an array of `Attachment`s elements of which points to `ShadowNode`s that form attachments;
* Now we use single `AttributedString` to construct result instead of concatenation objects recurvily walking the tree.
We will use the array of attachments later.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268048
fbshipit-source-id: 371c548826bdfd5c4f4b18915d68977724885ce6
Summary:
Adds `TextKind` trait to Paragraph and TextInput shadow nodes.
Later on it could cause confusion why they do not have this trait.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D20254008
fbshipit-source-id: 56fb264fa4fe38a5f00f080558cdc7992fd51fea
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:
Changelog: [Internal]
Use LayoutContext to pass `fontSizeMultiplier` down to ParagrapShadowNode.
Reviewed By: shergin
Differential Revision: D20184596
fbshipit-source-id: 3965a127069a21328ed19cb3f9732f0a2d1c4d58
Summary:
In order to build dynamic text sizing, `LayoutableShadowNode::measure` needs to accept `LayoutContext`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184598
fbshipit-source-id: 8928b59d51948caf3654f40049212a89a91dceb6
Summary:
Clearing `props` and `state` (which we don't use) allows avoiding retain cycles.
The memory leak was caused by a retain cycle:
AttributedString -> Fragment -> ShadowView -> PharagraphState -> TextLayoutManager -> Cache -> AttributedString.
We don't use `props` and `state` parts of `ShadowView` inside `AttributedString`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20182791
fbshipit-source-id: 2ddc5d53a1cb594e3d1cc39933e8958eb6425389
Summary:
This is a very crucial change, everything else in this stack depends on it.
Here is the set of constraints that we have for ShadowNode-based class hierarchy:
* `ShadowNode` is a base class that defines basic operations on the nodes. It does not have virtual methods by design (virtual dispatch hurts performance; we want to limit and centralize that in `ComponentDescriptor`s).
* `ConcreteShadowNode<>` template *statically* wires particular `ShadowNode` and particular `Props` establishing a type-safe relationship between them ensured on compile time.
* Not all `ShadowNode`s are "layoutable", not all "layoutable" `ShadowNode`s use Yoga to do layout.
* Layotability (and YogaLayotability) feature is implemented as two classes `LayoutableShadowNode` and `YogaLayoutableShadowNode`. These classes essentially need to know something about the ShadowNode nature of the object (get the list of children or replace some children).
Before the change, `LayoutableShadowNode` and `YogaLayoutableShadowNode`classes did not inherit `ShadowNode` because we don't want to use *virtual inheritance* for `ShadowNode`: `ConcreteShadowNode<>` already inherits `ShadowNode`, so if we make `LayoutableShadowNode` inherits `ShadowNode`, we will have to somehow flatten this inheritance hierarchy (and the virtual inheritance is an answer to that). (Yes, C++ supports multiple inheritance and virtual inheritance.)
Before this change, we solved this dilemma this way: We have a subclass-template `ConcreteViewShadowNode<>` that inherits `ConcreteShadowNode<>` and `YogaLayoutableShadowNode`. Then, we had a bunch of methods that implement the rerouting of some functionality from `YogaLayoutableShadowNode` to `ShadowNode` and vise-versa. (See the diagram "Before".)
That worked fine, except the caveats:
* That wiring is nasty, complex, hard to reason about and overall limiting.
* There is no way to statically cast `LayoutableShadowNode` to `ShadowNode` (because there is no common base class). That forces us to use dynamic_cast on some perf critical paths (including layout, diffing and so on).
* Adding features that rely on interop between `LayoutableShadowNode` and `ShadowNode` is a nightmare.
It should be a better way to deal with this dilemma, and this diff implements a different approach: We can have a base class of `ConcreteShadowNode<>` as a template parameter. With this approach, we can make `LayoutableShadowNode` inherit `ShadowNode` and when we need to instantiate a `ConcreteShadowNode<>` that needs to be layoutable, we can just specify `YogaLayoutableShadowNode` as a base class. (See the diagram "After".)
This simple change will allow us to simplify a lot of things. The rest of the stack is about getting rid of unnecessary moving parts. Which will finally allow us to build "Inline Views" feature.
```
╭──────────────────────╮
│ ◎ ○ ○ ░░░░░░░░░░░░░░░│
├──────────────────────┤
│ │
│ │
│ Before │
│ │ ┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │ │ │
│ │ │ ShadowNode │ │ LayoutableShadowNode │
└──────────────────────┘ │ │ │ │
└────────────────────────────┘ └────────────────────────────┘
▲ ▲
│ │
╔════════════════════════════╗ ┌────────────────────────────┐
║ ║ │ │
┌────────�║ ConcreteShadowNode<> ║ │ YogaLayoutableShadowNode │
│ ║ ║ │ │
│ ╚════════════════════════════╝ └────────────────────────────┘
│ ▲ ▲
│ │ │
│ │ │
│ │ │
│ │ ╔════════════════════════════╗ │
│ │ ║ ║ │
│ └─────║ ConcreteViewShadowNode<> ║─┘
│ ║ ║
│ ╚════════════════════════════╝
│ ▲
│ │
│ ┌──────────────┴───────────────┐
│ │ │
│ │ │
│ │ │
┌────────────────────────────┐ ┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │ │ │
│ TextShadowNode │ │ ViewShadowNode │ │ ParagraphShadowNode │
│ │ │ │ │ │
└────────────────────────────┘ └────────────────────────────┘ └────────────────────────────┘
╭──────────────────────╮
│ ◎ ○ ○ ░░░░░░░░░░░░░░░│
├──────────────────────┤
│ │ ┌────────────────────────────┐
│ │ │ │
│ After │ │ ShadowNode │
│ │ │ │
│ │ └────────────────────────────┘
│ │ ▲
└──────────────────────┘ ┌────────────────────────────────────┤
│ │
│ ╔════════════════════════════╗
┌────────────────────────────┐ ║ ConcreteShadowNode ║
│ │ ║ <Base: ShadowNode> ║
│ LayoutableShadowNode │ ║ ║
│ │ ╚════════════════════════════╝
└────────────────────────────┘ ▲
▲ │
│ ┌────────────────────────────┐
┌────────────────────────────┐ │ │
│ │ │ TextShadowNode │
│ YogaLayoutableShadowNode │ │ │
│ │ └────────────────────────────┘
└────────────────────────────┘
▲
│
╔════════════════════════════╗
║ ConcreteShadowNode ║
║ <Base: ║
║ YogaLayoutableShadowNode> ║
╚════════════════════════════╝
▲
│
╔════════════════════════════╗
║ ║
║ ConcreteViewShadowNode<> ║
║ ║
╚════════════════════════════╝
▲
├─────────────────────────────────────┐
│ │
┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │
│ ParagraphShadowNode │ │ ViewShadowNode │
│ │ │ │
└────────────────────────────┘ └────────────────────────────┘
```
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19963353
fbshipit-source-id: b65c8a5064bdb54ab64f08a8e546aa9e2b5a486b
Summary:
Having the overridden function that returns a different type is apparently not a good idea (and might cause bugs and unexpected behavior), so it was renamed. The function also got a new return type (`const &` instead of `std::shared_ptr`) for simplicity, better performance, and smaller code size.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19837694
fbshipit-source-id: b7a96424bd040409371724907b3fb3931cd8a2e8
Summary:
This pull request fixes a few `#include`s in the Fabric source:
* Changes `<Glog/logging.h>` to `<glog/logging.h>` in two files, which was an issue for case-sensitive file systems
* In `ParagraphProps.cpp`, changes the include of `attributedstring/primitives.h` from a relative style to a more absolute style.
## Changelog
[Internal] [Fixed] - Fabric: Fix various includes
Pull Request resolved: https://github.com/facebook/react-native/pull/27947
Test Plan: Fabric compiles perfectly, and the Fabric test suite passes.
Reviewed By: shergin
Differential Revision: D19788148
Pulled By: sammy-SC
fbshipit-source-id: 30a297e8aea50c7c7fd5f48745edf04811a6bdbd
Summary:
The reason for this change is that it is the primary root that we want people to be using and the naming should reflect that.
#nocancel
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Changelog: [Internal]
Oncall Short Name: fbobjc_sheriff
Differential Revision: D19431128
fbshipit-source-id: c7208e20ed0f5f5eb6c2849428c09a6d4af9b6f3
Summary:
Replace with `:container_evicting_cache_map`
Changelog: [Internal]
Rename `//xplat/folly:evicting_cache_map` to `//xplat/folly:container_eviciting_cache_map` to follow the new target name conventions
Reviewed By: JoshuaGross, nlutsenko
Differential Revision: D19374914
fbshipit-source-id: fadcaeac20fe61af79e1eecb1be5642f2ef96285
Summary:
This diff changes the signature of ComponentDescriptor constructor to make it simpler and easier to support: now all arguments are passed via struct that contains all these arguments as fields.
Now the ComponentDescriptor constructor accepts three arguments one of which is optional. This causes some confusion and the possibility of bugs in all subclasses that needs to implement a custom constructor. Mostly because in every case we need to ensure that the constructor:
* Accepts and pass down all parameters/arguments;
* Accepts the right types of those parameters (shared vs weak pointers, references vs values).
* Accepts all thee arguments and pass them (including flavor!). We failed this point several times.
Overal that makes the code simpler and allows changing the set of parameters relatively easy. (There is no plan for it!)
Look at the LOC balance: less code!
Changelog: [INTERNAL]
Reviewed By: sammy-SC
Differential Revision: D18548173
fbshipit-source-id: 5d038b135e004f6c054026b3235ed57db99c086d
Summary:
Having automatic defaults/an optional arg for `convertRawProp` has caused way more problems than it is worth. Remove the default argument.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19151594
fbshipit-source-id: 839ec8d138b2c3c083f221a2871582454004648c
Summary:
Motivation: in Marketplace, there's a TextInput in JS that sends { lineHeight: null } to C++. In Paper this was correctly handled as a default value, which just causes that property to not be set. In C++ in Fabric, it was being parsed incorrectly as 0 (because of incorrect defaults being passed into `convertRawProp`), causing the text to not be visible at all. The solution is to make sure that its default value is NaN, which is handled correctly, and causes the Text to render again.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19128049
fbshipit-source-id: fe985428f3ed8b90d56cfa387fbc2d1476d19d36
Summary:
Here the deal with the clamp thing:
A layout engine asks nodes to measure their content providing layout constraints (min and max size) and that would be kind from nodes to return a result that in space of those constraints. Sometimes, satisfying that is an additional separate step of that operation, e.g. if we know that the intrinsic size of some node is `{100, 100}`, we need to clamp that to satisfy constraint `[min: {200, 200}, max: {inf, inf}]`.
In case when we need to cache measure information, it becomes tricky enough when we need to make the cache work most efficiently. For the case of measuring Text, we have an insight: the available maximum width is important, the rest three metrics (maximum height and minimum size) are not.
That means that any changes in those three metrics don't affect the actual measurement result but will affect the final value because the actual value will be clamped by constraints that didn't influence measuring in the first place.
That's why moving clamping outside of a cache is the first step into making it more efficient.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848584
fbshipit-source-id: 8feeb3f1a9d0e9691abac8be43639487a626fec3
Summary:
The diff implements a new class called `AttributedStringBox` that represents an object storing a shared `AttributedString` *or* a shared pointer to some opaque platform-specific object that can be used as an attributed string. The class serves two main purposes:
- Represent type-erased attributed string entity (which can be platform-specific or platform-independent);
- Represent a container that can be copied with constant complexity.
Why? Several reasons:
- Sometimes it makes sense to keep an attributed string as a shared resource. This way we don't need to pay for expensive copying and we also implement a copy-on-write semantics on top of that if needed.
- We need to extend a TextLayoutMeasure API to support measuring some platform-specific attributed string implementation to remove the necessity of converting a string back and forth between representations. That's especially important for TextInput because we will need to measure that very efficiently (and the source of measuring, in this case, is a platform attributed string).
In other words, we need something to store inside TextInputState to measure and update very efficiently. The source of this data might be a native TextInput control or a data from React, to represent that kinda object we need this data structure (and interfaces that deal with it).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18670793
fbshipit-source-id: bc0164f801f28642f7c6da340af12acf33b85d24
Summary:
iOS and other platforms have direct access to C++ StateT structs, whereas Java only has access to a Java map equivalent - state updates from Java can't update complex types, or must incur significant cost to reconstruct large objects from their folly::dynamic representation (not to mention the complexity of implementing the Java-to-C++ struct converters). Thus it's hard for Java to update StateT's with complex types on the C++ side.
This diff makes a minor change to Android's updateState which uses both the folly::dynamic data from Java as well as the previous State, so each StateT can have fields that are read-only from the Java perspective.
Motivation: For AndroidTextInput we need to set params from Java, without being able to send all of the State params from Java.
In this diff, we introduce a new State constructor that takes the previous State value and a folly::dynamic. It is up to each State implementation how the additional parameter will be used.
We migrate every existing component except for AndroidTextInput in this diff.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18672365
fbshipit-source-id: 4469e0a3c7658c204089c6fed39394979883f124
Summary:
Use a similar setup as Paragraph, and support in Fabric:
- Correct measuring of AndroidTextInput
- Correct display of AndroidTextInput attributed strings
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18669957
fbshipit-source-id: 84e0ad8021c9edf8219e0c673c781276ca29787d
Summary:
Before this change `AttributedString::Fragment` had two ShadowView objects (`shadowView` and `parentShadowView`). This diff unifies those two things into one. That allows us to save some CPU and memory and makes things a bit simpler. Besides that, now the length of NSAttributedString and AttributedString is now always the same (it's one Unicode character for an attachment for both).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607658
fbshipit-source-id: 502ae244e98a52694adc0d646650f8ea0d7922ae
Summary:
We need to call all custom base constructors as part of a custom constuctor of the superclass otherwise C++ will use the default one (and that's not what we want here).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607654
fbshipit-source-id: 6e6154ce4b546c0717a8a67e3c497dfcd696ec41
Summary:
We will have several consumers for the measure infra soon (TextInput will use the same TextLayoutManager). It makes sense to move the cache there.
In the future, iOS and Android implementations will probably use a bit different (platform-specific) cache implementations because we will implement the ability to measure "opaque"/platform-specific text containers alongside with normal AttributeStrings.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18445855
fbshipit-source-id: 7b7a65152ac13c74525da695612ae034904e82bf
Summary:
As soon as we have traits infra, it's pretty straight-forward to implement this kinda flag. Without the traits, it's challenging to build that in a performant and elegant way. The challenges of the dynamic_cast-involved approach are:
* How to check for that feature in YogaLayoutableShadowNode?
* Even if we use `dynamic_cast`, to which class to cast?
* We also need to do that in constructor... and dynamic_cast-like checks for `this` don't work in constructors (C++ design limitation).
* How to scale that if we have more classes like Paragraph (and we will have it for sure)?
* Performance.
* Relying on RTTI.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18525347
fbshipit-source-id: b1915f43ff3fe4364ab6345fb9d1becc591b5a35
Summary:
This diff exposes textBreakStrategy as part of ParagraphAttributes. This is necessary to support the textBreakStrategy prop into Text for Android
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18101404
fbshipit-source-id: e7b665cefe48cf8c764f73a1c51eede16245d1ec
Summary:
This diff extends ParagraphState to expose not only the AttributedString associated to Text components, but also ParagraphAttributes that describes the visual high level props of the Paragraph
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18101407
fbshipit-source-id: 5f5d5ca35cc03e4bf983fd24654be9506d1901a1
Summary:
This is another step on the journey of removing `enable_shared_from_this`.
It's unclear why we used that before but it's clear now that using shared_ptr here is not necessary because all computation around happens inside the single callstack, so by definition we don't have object life-time concerns here.
Changelog: [Internal] Small Fabric-specific optimization.
Reviewed By: sammy-SC
Differential Revision: D17973957
fbshipit-source-id: 09a65c78e22083ed21b041240307f4858379cc60
Joshua Gross
Ishan Khot
Kevin Gozali
Samuel Susla
Nikita Lutsenko
Valentin Shergin
David Vacca
Adam Ernst
Janette Cheng
Josh Leibsly
empyrical
Michael Lee (Engineering)
Andres Suarez