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:
Custom containers are only enabled in release mode.
Using custom stuff complicates debugging process because it breaks embedded into IDE introspections mechanisms.
Reviewed By: mdvacca
Differential Revision: D14508299
fbshipit-source-id: d2dbe87764b17d75ccd544c0a4baf03dd9e0cd0b
Summary:
SharedShadowNodeList is one of the core collections in Fabric. Every ShadowNode has one, it's used intensivly during diffing and so on.
Usually, nodes have a very few children, so using `small_vector` instead of regular `vector` should save us a lot of memory allocations.
Reviewed By: JoshuaGross
Differential Revision: D14249201
fbshipit-source-id: 53297caa027a74099d0a1ed4a3cce78f8feb651b
Summary: Well, that was not so good idea to add that in the first place. Turns out that nowadays standard `string` and `vector` are good enought (but we still need small and inlined collections thought).
Reviewed By: JoshuaGross
Differential Revision: D14249202
fbshipit-source-id: a1b32b800c3f52b29a57f015e1221a0a0eb305c8
Summary:
In React Native there are several use cases where React State is not the only input that affects the component tree. E.g., in case of a <Modal> component, the screen size directly affects the layout of components inside modal; in the case of uncontrolled <TextInput> component, the text inside the input affects the layout of the surrounding components. `State` is a special (legit!) workaround for all those similar cases. Native part of React Native maintains a special shared object between all nodes of the same family and use that during cloning and commits.
See coming commits to know how to use that.
In the near future State will fully replace LocalData concept but for simplicity they both exist for now.
Reviewed By: mdvacca
Differential Revision: D14217184
fbshipit-source-id: 6e018c5b68208d662462013bce0f4e2733d2f673
Summary:
`SharedFunction` implements a pattern of a shared callable object that contains the same executable inside. It's similar to `std::function` with one important difference: when the object is copied, the stored function (and captured values) are shared between instances (not copied).
`SharedFunction` can be stored inside `std::function` because it's callable.
It useful in some scenarios, such as:
* When captured by `std::function` arguments are not copyable;
* When we need to replace the content of the callable later on the go.
We will use it in the coming diffs.
Reviewed By: mdvacca
Differential Revision: D14072078
fbshipit-source-id: 9df4ad2d1b92394e2dfef5c283f35c7c0bd4b500
Summary:
`Better` is a trivial collection of basic tools borrowed from other low-level general purpose libraries (like Folly, Abseil or Boost). The main goals of Better:
- Make the codebase more portable;
- Make the dependency list explicit (by decoupling it as a dependency list of Better);
- Make relying on modern C++ patterns and tools in code simple and easy.
- Make executing experiments with different dependencies easier.
As a first example usage, this diff replaces std::unordered_map with an efficient one from folly on the one of the hottest paths.
Reviewed By: JoshuaGross
Differential Revision: D13944565
fbshipit-source-id: 5fa2c4abe6c17f7361eddcc25f968b6440d5d9db
Andres Suarez
Janette Cheng
Adam Ernst
Valentin Shergin
Jonathan Kim