Summary: This diff open sources Fabric Android implementation and it extracts ComponentDescriptorFactory into a function that can be "injected" per application
Reviewed By: shergin
Differential Revision: D13616172
fbshipit-source-id: 7b7a6461216740b5a1ad5ebbead9e37de4570221
Summary:
This diff fixes a race condition that was detected on "Marketplace You" production test for Android.
The race condition happens when the method ShadowTree::complete is executed concurrently from two threads (in this case this is called from Scheduller::constraintSurfaceLayout and Scheduler::uiManagerDidFinishTransaction), based on the order of execution this bug makes MountViewItems to be dispatched to the UI in the wrong order.
The root cause of the bug is in the method:
```
bool ShadowTree::complete(
const SharedRootShadowNode &oldRootShadowNode,
const UnsharedRootShadowNode &newRootShadowNode) const {
newRootShadowNode->layout();
newRootShadowNode->sealRecursive();
auto mutations =
calculateShadowViewMutations(*oldRootShadowNode, *newRootShadowNode);
if (!commit(oldRootShadowNode, newRootShadowNode, mutations)) {
return false;
}
emitLayoutEvents(mutations);
if (delegate_) {
delegate_->shadowTreeDidCommit(*this, mutations);
}
return true;
}
```
Notes:
- the commit method is guarded by the commitMutex_
- the shadowTreeDidCommit() method dispatches mutations instructions to the platform side.
- If there are two threads running concurrently, there is no guarantee that the shadowTreeDidCommit() is going to be called in the correct order.
The solution is to include the execution to shadowTreeDidCommit() in the same commitMutex_
Possible solutions:
1 - move the commitMutex_ out of the commit method (to the completeMethod)
2 - synchronize the call to complete method() - this is the implemented solution.
I chose this solution to make it consistent with the way Scheduler::constraintSurfaceLayout is implemented (https://fburl.com/8l49no5x)
This mechanism is very likely to change in the refactor of threading mechanism that Valentin Shergin is going to be working on January.
I would like to land this, so we can fix this bug and run another experiment in production as soon as possible.
Reviewed By: sahrens
Differential Revision: D13535587
fbshipit-source-id: bedd4d85f5569ab3733c302d1328aa48017bcaad
Summary:
shergin mentioned that he'd like to move away from RTTI a bit and use explicit key strings for context container instances rather than relying on the `typeid`, so this does this.
We also fatal with a useful error message if we get a collision, rather than failing silently.
Reviewed By: shergin
Differential Revision: D13384308
fbshipit-source-id: 0b06d7555b082be89e8f130c23e94be99749a7a3
Summary: We need a way for different apps to inject dependencies or additional functionality into Fabric - ReactNativeConfig might be a special case, but I think this could clean up it's integration nicely, and I'm using this for a uitemplate cache system so we can use CompactDisk or other storage systems for caching depending on the app.
Reviewed By: mdvacca
Differential Revision: D13407287
fbshipit-source-id: 45481908434e6235850aa4d2d6b2bfb936a23be7
Summary:
In some setup, buck cxx test for android runs with `NDEBUG` set, hence we can't call debug symbols in the test cases. So guard those callsites with `#ifndef NDEBUG`.
Also, some dependencies for this test target depend on Android specific symbols, so we have to mark it as instrumentation test for now (FB-specific).
Reviewed By: sahrens
Differential Revision: D13337637
fbshipit-source-id: 02ff152df9937f2b0b8596f53789cdee8ee8a539
Summary: For configuration purpose, pass down config object from the hosting app and use it in UITemplateProcessor.
Reviewed By: sahrens
Differential Revision: D13290322
fbshipit-source-id: 8bb6d7f5a3f977b873e548e15603259876b46dc8
Summary:
`ShadowTree` class is already thread-safe, so we don't need to (we should not) guard concurent access to it.
We should guard concurrent write-access to the collection of them though.
Note that unordered_map is "thread-compatible" collection, so concurrent reading access is okay.
Reviewed By: mdvacca
Differential Revision: D13269745
fbshipit-source-id: 4779626018da0e42b81a835e538f6c1d1a8e25f7
Summary:
Now the event delive pipeline supports `JSI::Value`-based payload. Instead of passing `folly::dynamic`, now we are passing `std::function<jsi::Value(jsi::Runtime &runtime)>` as factory that can build a `JSI::Value` with given `jsi::Runtime` and any captured data.
The old (now legacy) way of calling `EventEmitter::dispatchEvent(..., const folly::dynamic &payload, ...)` is also supported.
Reviewed By: sahrens
Differential Revision: D13123043
fbshipit-source-id: d65348bb215013042abb2fcfe5083a8c697333d0
Summary: Now instead of passing `reactTag` through the whole event pipeline, we store it inside `EventTargetWrapper` (and it does not leave `UIManagerBinding`). It helps with reducing the complexity of `EventEmitter` and will help us in migrating to JSI.
Reviewed By: sahrens
Differential Revision: D13123045
fbshipit-source-id: aa9ee94d5660ff3090369c1e55cf748d2e72b987
Summary:
ShadowView, ShadowViewMutation, and Differentiator were decoupled to separate module.
That enables us to use ShadowView more widely without facing a circular dependency problem.
Reviewed By: mdvacca
Differential Revision: D13205229
fbshipit-source-id: 7373864bf153a7813c2f97edb263a41454ce0b88
Summary: Pretty straightforward wiring UIManager and the new feature in ShadowTree: we get the node, clone with the new props and then replace this.
Reviewed By: sahrens
Differential Revision: D13114788
fbshipit-source-id: 3a34fb879f3ec564c26278034a19b88518302de8
Summary: This method is the core of the future features: `setNativeProps` and `LocalState`.
Reviewed By: sahrens
Differential Revision: D13114789
fbshipit-source-id: 2138496c43c171fe27784b1959d86d6eec4638ee
Summary:
Apparently, the previous behavior brings more problems than some *possible-in-the-future* features and flexibility.
The new model allows us to easily implement "nested text" feature.
(We temporary hope the old behavious for Android only for compatibility reasons.)
Reviewed By: mdvacca
Differential Revision: D13176277
fbshipit-source-id: 01f7bfb3c2e70cc89d76ecb78add016ee91cbd63
Summary: This method is underlying infra for all `measure`-like methods exposed to JavaScript.
Reviewed By: mdvacca
Differential Revision: D13036553
fbshipit-source-id: cb5135f1db97ec8144b31a24ee4fb9f5d61f0df1
Summary: The diff adds a pointer to ShadowTreeRegistry to UIManager which enables the possibility of implementing ShadowTree mutating and inspecting methods like `setNativeProps` and `getRelativeLayoutMetrics`.
Reviewed By: mdvacca
Differential Revision: D13036549
fbshipit-source-id: 5ed1252d84c8dd895fe0e6e8cc71afbaa9dab4b7
Summary:
Why do we need a dedicated registry class?
* We need to simplify registry-related logic in Scheduler.
* We need to couple threading aspect of the registry with the registry itself, otherwise it's not clear why exactly we acquire the mutex. We also should not acquire the mutex in a per-method way (as we did before), because it's incorrect and misleading (only lines that access the registry should by protected).
* We need to have a way to share the registry with other classes (e.g. UIManager) without passing a reference to the whole Scheduler.
Reviewed By: mdvacca
Differential Revision: D13036550
fbshipit-source-id: 644da910e823666c586834a3da2b4cdcb90eebb2
Summary: Trivial. Those are not used.
Reviewed By: fkgozali
Differential Revision: D13017883
fbshipit-source-id: cf285e537eb85c8fca6852f7c03a5ef661b85757
Summary:
This pull request fixes a path name to be a proper case in `UITemplateProcessor`, which fixes this build warning:
```
{snip}/react/uimanager/UITemplateProcessor.cpp:17:10: warning: non-portable path to file '<react/core/ComponentDescriptor.h>';
specified path differs in case from file name on disk [-Wnonportable-include-path]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<react/core/ComponentDescriptor.h>
1 warning generated.
```
Pull Request resolved: https://github.com/facebook/react-native/pull/22239
Differential Revision: D13020871
Pulled By: shergin
fbshipit-source-id: 77555018cd569880518ff884ed8768effc4ea97e
Summary: This diff changes the behavior of the Scheduler.schedulerDidRequestPreliminaryViewAllocation to avoid pre-allocating views that are non-layoutables
Reviewed By: shergin
Differential Revision: D12962008
fbshipit-source-id: cb2670beafdcbd2116fbdaf2dc5d1b4726330ec2
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: In the previous approach, when event emitter got disabled for split second, we could lose the EventTarget because JS GC can collect it before we re-enable this. Now we "over-enable" this first, and "under-disable" later.
Reviewed By: mdvacca
Differential Revision: D12990112
fbshipit-source-id: 4e3c0c0e05f03509ec72ca570f59ce16597353f0
Summary: ShimmeringView is called: RTShimmeringView Android and ShimmeringView in iOS. This diff adds a mapping into ComponentDescriptorRegistry to temporary enable ShimmeringView component until we can unify names in JS.
Reviewed By: sahrens
Differential Revision: D12991351
fbshipit-source-id: 48e08b8021116221ccfd5f2512c76f65145baa2a
Summary: This diff exposes rootTag as part of SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation(). This will be necessary to be able to pool views per Surface in Android
Reviewed By: shergin
Differential Revision: D12875656
fbshipit-source-id: d2a8c1f9bcc6b14c17b34bf59085da44ae3c3416
Summary: This diff adds systrace support in the C++ side of Fabric
Reviewed By: ejanzer
Differential Revision: D12861373
fbshipit-source-id: 0291f3e406f239bbef3686ac0bba6e9f1c7eac57
Summary: AndroidSwipeRefreshLayout is rendered in the "Marketplace Your Items" screen altough it is disabled. This diff just temporary implements the AndroidSwipeRefreshLayout component as a View (similar to the iOS counterpart RefreshControl).
Reviewed By: shergin
Differential Revision: D10524049
fbshipit-source-id: 5df38fbdf1339b3857138d82a7100ec7f15854b3
Summary:
This diff changes how we expose UIManager to JavaScript realm and control ownership of it. This change should improve reliability and a thread-safety.
UIManagerBinding is a HostObject which consolidate ownership of UIManager. Now JavaScript's GC controls its lifetime which eliminates the possibility of calling some JS facing methods of UIManager using a dangling pointer.
Besides that, all API now imply that if the caller has a reference to jsi::Runtime, it calls the method on the proper thread (it's an implication of RuntimeExecutor design).
Reviewed By: sahrens
Differential Revision: D12876745
fbshipit-source-id: eb8c70317460df5b14e45031ad15fc6c8e5b5ce3
Summary: We need to decouple this from actual JSI/UIManagerBinding implementation to make them more maintainable.
Reviewed By: sahrens
Differential Revision: D12876742
fbshipit-source-id: 30cad69d0a9761e2aa82f31d180e4b5a40cedb61
Summary: This is more usable (because it allows to use `->` operator) and safe (const-style) methods replacing old `operator[]` methods.
Reviewed By: mdvacca
Differential Revision: D12876744
fbshipit-source-id: 8ea7398c9777f8be3e88db873ec00915d0761615
Summary:
We double down on JSI in Fabric. So, practically, JSI is now a hard dependency for Fabric. I hope it's for good.
Now `jsi::Runtime` is coupled with scheduling via `EventExecuter`, so we have to make `jsi::Runtime` a part of `EventBeat` to proxy runtime reference to bindgings.
Reviewed By: sahrens
Differential Revision: D12837225
fbshipit-source-id: 98edc33d6a3358e6c2905f2f03ce0004a9ca0503
Summary: React bytecode is kind of a different thing that sebmarkbage already has in mind so lets keep the namespace separate.
Reviewed By: mdvacca
Differential Revision: D12896293
fbshipit-source-id: e0f266da6e7a051bcf5defea49b958452342754d
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary:
* Adds parent tag as param for createNode in place of explicit appendChild commands.
* Adds version info to bytecode
* Adds native conditional support:
Conditionals are represented in product code with the new `NativeConditional` React
component. It takes params necessary to construct a native function call, and takes
a render prop as a child that passes the value of the native call as an arg. In
prod, the component would actually call the native module and render with that value,
but in jest we render for *both* true and false and set them as children
of a new jest-only primitive/host component which we special-case and generate a
special command with `OP_CODE.conditional`, generate the appropriate bytecode commands
for each branch, and embed them as args in the conditional OP_CODE command. When
evaluating the bytecode, only one set of commands is executed, based on the native
module value (which is evaluated with another new opcode which computes the value
and stuffs it in a "register").
Obviously generating this bytecode is kind of a cludge compared to prepack, but
when I asked @[501709947:Dominic] about it, he said they had no bytecode spec right
now, so I'm running ahead with this prototype. The main thing I'm focused on is
the C++/RN bytecode interpretter - this jest stuff is just a way to generate bytecode
for it to consume which could be replaced or augmented with many other approaches,
such as prepack, server rendering, etc.
Also piggybacked a bunch of other cleanup.
Reviewed By: shergin
Differential Revision: D10277121
fbshipit-source-id: 15d3217a59ef481b574c742d17d8a7dc893cba90
Summary:
This diff introduces a new integration concept (called RuntimeExecutor) which consolidates `Runtime` and the dispatching mechanism.
As simple as that:
`using RuntimeExecutor = std::function<void(std::function<void(facebook::jsi::Runtime &runtime)> &&callback)>;`
Reviewed By: fkgozali
Differential Revision: D12816746
fbshipit-source-id: 9e27ef16b98af861d494fe50c7e50bd0536e6aaf
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: Simplies UIManager a bit and some other tweaks
Reviewed By: shergin
Differential Revision: D10211883
fbshipit-source-id: 93ab23dd2baab2fdc6d9c54e976b001a19efab7f
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: Quite obviously, having a `complete` method which accepts only `newRootShadowNode` was a baaad idea. When we `complete` or `commit` we always have to have two nodes (before and after). And only after layout and right before swapping (and acquiring the mutex) we have to verify that *current* root node is still the same as it was when we initialized the transaction (if not, we have to abort).
Reviewed By: mdvacca
Differential Revision: D10201902
fbshipit-source-id: 15adc78c5d31d6fd39fd7fc6e53203a5539717a8
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
Summary: With new `ShadowTree::getRootShadowNode()` method all access to rootShadowNode_ is protected by commit mutex.
Reviewed By: mdvacca
Differential Revision: D10159456
fbshipit-source-id: 0bc8676ca2564a8ef95d60e912356e99d9f172c1
