Summary:
Easy diff to document in code how to enable logging of Shadow Tree instrospection
changeLog: [Internal] Internal change used on Fabric
Reviewed By: JoshuaGross
Differential Revision: D21150196
fbshipit-source-id: 8eb23ec3ea1d574b79b09333428ab52c851065dd
Summary:
Yoga uses `std::array` a lot (and `std::array` is not a `std::vector`), so it's useful for printing Yoga values.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028570
fbshipit-source-id: c6bf114d5362f085ea201ecdc5b7d59646b33ebd
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:
The new name is get_preprocessor_flags_for_build_mode.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D20351718
fbshipit-source-id: 67628ce81e7244f0f72af2d00d92842a649ff619
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:
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:
Having those arguments optional does not really make anything easier to use; on another side that makes it hard finding problems caused by missing that parameter.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18797337
fbshipit-source-id: c119b8f6a03994072edb45e39337e33b0f8b602f
Summary:
`xplat` targets add different deps based on what platform the target is being built for.
for anything using `fb_xplat`, we can put all ios supermodules in `fbobjc_labels` and all android sms in `fbandroid_labels`
There's some weirdness with python targets like `thrift_gen` in `/xplat/mobileconfig/tools/generator/gen-py/BUCK` that don't have platform-specific labels because the except_for list for `fbandroid` doesn't need the `fbsource//` prefix (see changes in `/ios/isolation/infra.mobileconfig.sm`)
Changelog: [Internal]
Reviewed By: shergin, joshleibsly
Differential Revision: D17884952
fbshipit-source-id: e245364cf515b75682990094d24f789d53b1f3f5
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:
Informal `DebugStringConvertible` interface serves the same purpose as `DebugStringConvertible` abstract class (providing universal pretty-printing interface) but relies on C++ static overloading instead of virtual dispatch.
This approach has some advantages and disadvantages:
Pros:
* It's more clear and scoped. It's simpler to implement debug-printing functionality aside of normal production code.
* It's more composable.
* It allows print types that are not classes.
* For some classes using `DebugStringConvertible` means that we have to use virtual inheritance (which might be undesirable and affect *production* performance (if a compiler isn't smart enough to remove empty base class).
* For some highly lean classes (that designed to be as small as possible) adding base (even empty-in-prod) classes kinda... smells.
Cons:
The particular implementations cannot rely on dynamic dispatch which can complicate printing classes with meaningful differences between sampling classes (e.g. ShadowNode subclasses). That's why we don't remove `DebugStringConvertible` class yet.
Reviewed By: mdvacca
Differential Revision: D14715081
fbshipit-source-id: 1d397dbf81dc6d1dff0cc3f64ad09f10afe0085d
Summary:
They need to be in DebugStringConvertible because it depends on they (and because `debugStringConvertibleUtils` depends on `DebugStringConvertible`).
We also moved they implementation to cpp file to avoid leaking Folly's features to consumer namespace.
Reviewed By: mdvacca
Differential Revision: D14715080
fbshipit-source-id: 7277e17b39a14a2d7ba7e5a9b44a70178feb1045
Summary:
* Small improvements in pretty-printing algorirhm (adding spaces and new-line caracters). Now it's even more pretty.
* The `depth` parameter was integrated into `DebugStringConvertibleOptions` which simplifies evething a bit and reduce amount of arguments that `getDebugDescription` requires.
Reviewed By: sahrens
Differential Revision: D14715082
fbshipit-source-id: 3ea0b8db3c1816c5cb43f40ccec9cdc1943f33a5
Summary:
This pull request removes a constructor in `DebugStringConvertibleItem.h` that was causing this issue in MSVC:
```
DebugStringConvertibleItem.cpp(20): error C2600: 'facebook::react::DebugStringConvertibleItem::DebugStringConvertibleItem': cannot define a compiler-generated special member function (must be declared in the class first)
```
It was likely conflicting with the constructor that has default values for all of its arguments.
[General] [Fixed] - Fixed `DebugStringConvertibleItem` compilation on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23436
Reviewed By: shergin
Differential Revision: D14067760
Pulled By: mdvacca
fbshipit-source-id: 303cf9b3559932c3d06514a1f3a8739d0f6f9dc2
Summary: All our C++ Fabric tests are cross-platform, so it makes sense to run them for all platforms (especially because platform may behaive differently).
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D13984574
fbshipit-source-id: e384c03c7f9839be38a1910e04ba2f7725abc378
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary: This diff adds systrace support in the C++ side of Fabric
Reviewed By: ejanzer
Differential Revision: D12861373
fbshipit-source-id: 0291f3e406f239bbef3686ac0bba6e9f1c7eac57
Summary: missing header and platform. attributedstring builds now, but still fails because of T34990592
Reviewed By: mdvacca
Differential Revision: D10349210
fbshipit-source-id: dcd163df9ac9a4fcb36399cb9f93dbf1b33c062d
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: That should save us some app size kilobytes.
Reviewed By: mdvacca
Differential Revision: D10081499
fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
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:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
Summary: Unused loads hurt readability and take time to process.
Reviewed By: hramos
Differential Revision: D9494120
fbshipit-source-id: 455b56efadab1cb976344cffcb427772bfda2f71
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:
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: Oh, my! No more `#define`s related to props conversions and debug-printing.
Reviewed By: fkgozali
Differential Revision: D7958250
fbshipit-source-id: 86950070c55f134aa3a575b9fd68fc90d865cf44
Summary:
We have to have automatic treatment for `optional` types. So, if we can process type `T` we can also automatically process `optional<T>.`
Support for optional allows us to not introduce new types (with embedded special "undefined" value) or pollute existing pure types (with special "undefined" value). (A lot of examples of those types can be found in AttributedString module.)
Reviewed By: fkgozali
Differential Revision: D7958249
fbshipit-source-id: 21af526a17dd0329e1262020cab8ecb902316654
Summary:
This diff opens a diffstack where we migrate the generation of all prop conversions (convertRawProp) and pretty-printing (debugStringConvertibleItem) functions to C++ templates (instead of using `#define`s).
So, this diff implements base versions of those functions as templated functions.
For now we still need #define-based version, but eventually, we will get rid of it.
Reviewed By: fkgozali
Differential Revision: D7958247
fbshipit-source-id: 24346297c1bd17e8054758f0eb84698eebfa21e2
Summary:
No macros in product code.
(Not all callsites are converted yet.)
Reviewed By: mdvacca
Differential Revision: D7797561
fbshipit-source-id: da899421bf99669a0e0a2b83df6004daf14355c2
Summary:
I was shamed by Sebastian's sebmarkbage concerns (totally unrelated to this topic) about introducing another level of indirection into the system and decided to change my original plan not to support text attributes for the <Paragraph> component.
So, now <Paragraph> shares <View>, <Text> and <Paragraph> itself capabilities. That reduces the minimum amount of required components for trivial text fragment from three (Paragraph, Text, RawText) to two (Paragraph and RawText).
Special thanks for C++ for supporting multiple inheritance.
Reviewed By: mdvacca
Differential Revision: D7785889
fbshipit-source-id: dd9f2e2650bfbfd76d7d4b538adaf409f9429df3