Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: mdvacca
Differential Revision: D21675808
fbshipit-source-id: b3ef44729bb8b6217f90760aec9737276c9601d1
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
TODOs:
- Use std::chrono for timekeeping
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: shergin
Differential Revision: D17486030
fbshipit-source-id: 95c72cf9fc2b4bf3fe652fbd249cf2ad113033c7
Summary:
This is a debug-only feature that simply should be an assert. When it triggers in debugger and bubbles to some random exception catch block which makes it impossible to understand was exactly it happens. Making it an assert will stop debugger exactly where it happens.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028571
fbshipit-source-id: 3df4ec0da922026bb9df61081cb71113577e06e9
Summary:
See previous diff implementing failing unit test in RawPropsTest.cpp.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18664014
fbshipit-source-id: ef827bce8c676666b2ce4d5db4abbb0ab11cc454
Summary:
See previous diff where I added RawPropsTest.cpp to unit-test this functionality. Before this, if you looked up a prop name that does not exist, the prop parser would enter an infinite loop.
I also took this opportunity to comment the block a little bit as it's not super intuitive at first glance.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18662135
fbshipit-source-id: 319a3b80d1c606db18b2added9f2aa99d4d03407
Summary:
This diff makes the parsing *Props object with sub-props with duplicating names deterministic: only the first one will be assigned. Before this change, the order was not guaranteed because `qsort` sorting algorithm is not stable and because binary search that we use to search in the sorted array does not handle duplicates deterministically.
The behavior when the only sub-prop (the first one) is being assigned actually desirable feature that exists on purpose. There are places where it's desired behavior (like TextInputProps) and in cases where it's not desired (we don't really have those), it's easy to "fix" implementing the custom constructor.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607657
fbshipit-source-id: aa53a320e6a48877a0dd1b9351dfcc8a9f419b38
Summary:
# LegacyViewManagerInterop is born
LegacyViewManagerInterop is a component that should make it possible for legacy components to work in Fabric, new renderer.
This is just a first stage that prints keys of props to screen together with component name.
Reviewed By: shergin
Differential Revision: D17552827
fbshipit-source-id: c3e062f413727729e6a9b683c60f59f0292cc63b
Summary:
This part of the codebase is very perf sensitive and designed to work without exceptions enabled.
Most of the method was `noexcept` all the time, but some of those missing that by mistake.
Reviewed By: sammy-SC
Differential Revision: D17629426
fbshipit-source-id: b311e4b7eff8e2b7cf29518288480d3a812dda44
Summary: Adds support for dynamic value that are `std::vector<std::vector<RawValue>>`
Reviewed By: shergin, mdvacca
Differential Revision: D16936932
fbshipit-source-id: fc8d087f9705af9da56ccc1bd9a0537b2bfeb50d
Summary:
Previously, we stored `keyIndex_` in a Parser object which is incorrect because it makes the parsing process thread-unsafe (the Parser is shared between parsing processes).
That worked previously most of the time because we never parsed props concurrently but we actually do this in the native animation library.
Reviewed By: yungsters
Differential Revision: D16064557
fbshipit-source-id: 211f4301d0746e0f5126a1dcdd59f1ae9a420aa9
Summary:
ComponentName is used by many core component of React Native, such as ComponentDescriptor, ShadowNode, ShadowView and so on. In all those cases this value represents the actual name of the component which came from `concreteComponentName` template parameter of ConcreteShadowNode. In all of those cases, it's raw `char const *` type. So, we don't need to use owning representation of the string (std::string) in all those places.
The only exception from this is a part where we receive the name of the component from JS side. In this case, the source string comes from JS and has to be analyzed as a character sequence to find corresponding ComponentDescriptor.
In my experiments, 20% of the time during diffing is spent on copying (this) `std::string`.
Reviewed By: mdvacca
Differential Revision: D15844407
fbshipit-source-id: a2e71505e22d09107e001bdf661d4a826bcf2dea
Summary:
This diff reimplements the prop parsing infrastructure in a part where it interacts with RawProps value.
Local synthetic tests show that the new way is 3x faster but the actual production result is quite unpredictable. MobileLab tests show some improvements about 10-20 ms on iPhone 6.
In short, the new way is faster because it inverts the lookup order and heavily relies on actual data types (and their properties) that we use. The old approach required about 130 hash-map lookups (where the key is `std::string`) to parse a single *Props object.
The new approach prepares concrete-props-specific tables with indexes of coming values ahead of time, iterates over raw data and puts it into those tables, and then performs a lookup in a very efficient manner.
Reviewed By: JoshuaGross
Differential Revision: D15752968
fbshipit-source-id: 847106e652eb7fc7ef7b99884a6f819ea3b9fd06
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: This is a small perf tweak that alone does not give much improvement but the coming diffs will rely on the possibility to construct empty RawProps object.
Reviewed By: mdvacca
Differential Revision: D15511494
fbshipit-source-id: 39dec9336e6b5cf6ad33b1f3a06ca1c096ece628
Summary: In methods which implement move semantic we have to check the source object because it's (also) being mutated.
Reviewed By: JoshuaGross
Differential Revision: D14496937
fbshipit-source-id: f3f2299d14e41c8b269f1647336dbd5b45c235f4
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: It can save us a couple of ms, hopefully.
Reviewed By: mdvacca
Differential Revision: D14249196
fbshipit-source-id: b5911bcd8b49be66de7b9d2da660df38ef7cc8cd
Summary:
Our long-term plan is to completely illuminate `jsi::Value`-to-`folly::dynamic` serialization step in prop parsing process improving performance and memory pressure. At the same time, we don't want to introduce a hard dependency in application code to JSI because it exposes direct access to VM and prevents parsing some data that come *NOT* from JSVM.
RawValue is an extremely light-weight (hopefully fully optimized-out) abstraction that provides limited JSON-like and C++-idiomatic interface.
The current particular implementation is still using `folly::dynamic` inside, but I have fully JSI-powered one which will replace the current one right after we figure out how to deal with folly::dynamic-specific callsites. Or we can implement RawValue in a hybrid manner if a code-size implication of that will be minimal.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D13962466
fbshipit-source-id: e848522fd242f21e9e771773f2103f1c1d9d7f21
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary:
There is no need to make JS calls to start or stop React Native apps; Scheduler does it automatically. Yay!
With this change (because we have to change Scheduler API) we are starting slow process migrating away from using term `reactRootTag` when we refer to running a ReactNative app (aka Surface). We will use `surfaceId` instead. We plan to slowly and gracefully retire `reactTag` term entity replacing it with several appropriate entities specific for particular usage, e.g. `viewId` (some id which makes sense for mounting), `surfaceId`, `nodeId` (unique id representing nodes which were cloned from the original one), or `eventTarget`.
Reviewed By: mdvacca
Differential Revision: D9999336
fbshipit-source-id: bbc7303c195b070b8c235c9ca35546d1dc693e98
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
Summary:
@public
Now, Sealable is already error-preventing-only mechanism, no business logic relies on that.
So, it makes sense to make it debug-only to illuminate possible performance impact.
Reviewed By: mdvacca
Differential Revision: D8923597
fbshipit-source-id: 80aa9097c4b719e91de73ac59f38d3a4751f0b06
Summary:
@public
We don't need to maintain an order of this collection, so using `unordered_map` is more appropriate.
Reviewed By: mdvacca
Differential Revision: D8826946
fbshipit-source-id: f6890097cc5d6a1e06f6b2cfd1b7d68a388da461
Summary:
Nothing actually changed besides type names... which actually helps me found an issue in FabricUIManager!
Now there is no a single `void *` in Fabric/C++ and JavaScript bindings. Yay!
Reviewed By: fkgozali
Differential Revision: D8191420
fbshipit-source-id: b1eb60b6bc34dd25ab200aab854ffbd7ccf5b15d
Summary: Slightly new approach: Some non-const methods might not always mutate objects, so sometimes we should call `ensureUnsealed()` only inside conditional branches where we actually mutate an instance.
Reviewed By: fkgozali
Differential Revision: D7467793
fbshipit-source-id: 1b9f229cf6816e54e0df36699a571fdb612d3c3c
Summary: Foundation clases for Fabric designed to be "const-first".
Reviewed By: fkgozali
Differential Revision: D7230672
fbshipit-source-id: 433acd35a7958d5d577358b0a306923f970e573f
Summary:
* Fixed semantic: all kinds of derivative instances lose `sealed` flag (which is expected);
* Using atomic<bool> for `sealed_` ivar.
Reviewed By: fkgozali
Differential Revision: D7230674
fbshipit-source-id: abe786610c20a45a0fabb9068120e24adeeeac7f
Summary:
`Sealable` class represents something which can be *sealed* (imperatively marked as immutable).
Authored by shergin
Reviewed By: shergin
Differential Revision: D7174883
fbshipit-source-id: 8b26ca5b1a5154953a099895778eab86228acc46
Joshua Gross
Ishan Khot
Valentin Shergin
Andres Suarez
Samuel Susla
Rick Hanlon
Min ho Kim
Héctor Ramos
Joe Peplowski
Kevin Gozali