Summary: Previously we had a single `commit` function that accepts an argument that enables auto-retry mechanism. As Spencer pointed out, that wasn't so useful and clear. So, I split the method into two with more expressive names.
Reviewed By: sahrens
Differential Revision: D13681594
fbshipit-source-id: 529f729d597206e9a0ac940f005a1569a9bef707
Summary:
I read my code and one thing stroke me: What if the same event emitter dispatches several events during the same event beat? In the previous implementation, only the first one will be delivered because the first `release` call consumes stored strong reference.
So, I changed the API a bit to make this more explicit: we have `retain` & `release` methods and we have a getter that works (multiple times) only if the object was successfully retained.
Reviewed By: sahrens
Differential Revision: D13668147
fbshipit-source-id: c00af5f15bc7e30aa704d46bd23584b918b6f75a
Summary: This diff implements a new algorithm that effectively marks `EventEmitter`s enabled or disabled. The previous implementation relied on a list of mutation instructions whereas the new one analyzes the shadow trees. The mutations-based approach didn't work well because mutations describe `ShadowView`s whereas some `ShadowNode`s are simply not views (like VirtualText), but we have to enable/disable them anyway.
Reviewed By: sahrens
Differential Revision: D13642594
fbshipit-source-id: 12169e11d5685e50bcd0d8c410498c594df744b4
Summary: The mutex is a "leaf" mutex, so the code cannot reenter that, so there is no reason to be a recursive one.
Reviewed By: sahrens
Differential Revision: D13642592
fbshipit-source-id: 0fb64d3405c5d3408251dc983c186f6747bc6ee2
Summary:
EventTargetWrapper and EventTarget were merged into one class that controls an `instanceHandle` reference and extracting a strong reference to it.
This diff also decouples the operation of retaining a strong reference (with checking a `enabled` flag) from actual usage of this reference. This allows to wrap into a mutex only first part of this process and avoid possible deadlocks.
Reviewed By: sahrens
Differential Revision: D13616382
fbshipit-source-id: 9907bc12047386fcf027929ae2ae41c0b727cd06
Summary: Because it was not idiomatic anyway. There is no point having a pointer to RootShadowNode without any guarantees that it's the current one. Using `commit` method makes this concern explicit.
Reviewed By: sahrens
Differential Revision: D13615363
fbshipit-source-id: f71ffc3c55dbdc69624933eb8b92334ed793c794
Summary:
Removing additional complexity from ShadowTree should help with maintainability. Now, this class is "tricky", but short at least.
With new `commit` API, it's much more simple and expected this way.
Reviewed By: sahrens
Differential Revision: D13615365
fbshipit-source-id: 1fe851c1a2d3bdc7ac2f4a570cf0170eae3c4c67
Summary: Now it's parts of RootShadowNode and Scheduler.
Reviewed By: sahrens
Differential Revision: D13615364
fbshipit-source-id: 13dbea1e69ef51b2679101915c01c6be7e15d859
Summary:
Instead of the whole family of commit* and complete* methods, now we have one single `commit` method which performs pre- and post-commit operations and swap pointers in a thread-safe manner. The `commit` operation is also exposing `revision` number and allows perform multiple commit attempts.
`completeByReplacingShadowNode`, `measure` and `constraintLayout` are also going away to RootShadowNode class in the next commits.
Why?
* Nicer API;
* No more recursive_mutex, no more problems with thread jumps;
* All mutex locks are now leaf-locks, so no more deadlocks possible;
* Exposing `revision` should help with debugging races.
Reviewed By: sahrens
Differential Revision: D13613942
fbshipit-source-id: 94e797d2f7860717847e823b5d97c4f7b35f08df
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
