Summary: This is a temporary change to measure production data
Reviewed By: fkgozali
Differential Revision: D13906807
fbshipit-source-id: 2a2f71aa379c4aca63c7bb4a9644704f713cb088
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:
For some time we have had a nit trick inside `EventEmitter`: When event emitter is disabled, we switch to store `EventTarget` as a weak pointer instead of complete deleting it. Given some unpredictability of JS GC, it gave us some time to restore the pointer in case if we increment the counter right after decrementing this. Apparently, we found that it doesn't always work (obviously, sigh...), so we implement the `enableCounter_` and left this feature as it is assuming that it can nice optimization that illuminates some unnecessary constraints.
But, apparently, it's actually harmful, assuming that `jsi::WeakObject` (that thing that we use to refer to actual JS target) actually has "unsafe unretained" (not "weak") semantic.
So, we have to remove this.
This change will be particularly important for coming diffs in the stack.
Reviewed By: mdvacca
Differential Revision: D13324480
fbshipit-source-id: 4c4da2984dc6a36b94b564bc9eee144142b430b0
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: 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: This diff adds systrace support in the C++ side of Fabric
Reviewed By: ejanzer
Differential Revision: D12861373
fbshipit-source-id: 0291f3e406f239bbef3686ac0bba6e9f1c7eac57
Summary:
The first implementation of EventEmitter's enable/disable feature didn't not provide a way to enable an object after it was disabled.
Apparently, we need this functionality due that fact that all nodes of the same family share same event emitter.
Reviewed By: mdvacca
Differential Revision: D10395849
fbshipit-source-id: 0eba54f0bb7ded35d64afb6559e6e27208c2b577
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: This diff unifies the 'handling' of the top prefix in the EventEmitter.cpp class
Reviewed By: shergin
Differential Revision: D10149497
fbshipit-source-id: d0ddbbbeefe3790b414b101da47582161354c971
Summary: Instead of relying on explicit `RawEventDispatchable` function, we simply check the existence of the `weak_ptr` to `EventTarget`. This is efficient and sufficient because only an EventEmitter retains an associated EventTarget.
Reviewed By: mdvacca
Differential Revision: D9764858
fbshipit-source-id: 4ac25d925f189d0f8b9002e52388fd51629934a8
Summary:
This diff implements a new model of managing `enabled` flag in EventEmitter.
Now we simply rely on `eventTarget_` is not being `nullptr` (and we reset the pointer to "disable" the event emitter).
Reviewed By: mdvacca
Differential Revision: D9764857
fbshipit-source-id: 1dd3ce0c8589048babbf2dbac9f8359358b31a34
Summary:
As we did in the previous diff, here we implemented `EventEmitter`'s ownership model as a `shared_ptr`. This change fixes problem with leaking `WeakObject`s which happens on hot-reload.
So, in short:
* `EventTargetWrapper` object owns `jsi::WeakObject` that can be converted to actual `jsi::Object` that represent event target in JavaScript realm;
* `EventTargetWrapper` and `jsi::WeakObject` objects must be deallocated as soon as native part does not need them anymore;
* `EventEmitter` objects retain `EventTarget` objects;
* `EventEmitter` can loose event target object in case if assosiated `ShadowNode` got unmounted (not deallocated); in this case `EventEmitter` is loosing possibility to dispatch event even if some mounting-layer code is still retaining it.
Reviewed By: mdvacca
Differential Revision: D9762755
fbshipit-source-id: 96e989767a32914db9f4627fce51b044c71f257a
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:
@public
Now, one of the main purposes of `EventEmitter`s is to create RawEvent instances for all specific event invocations.
Reviewed By: mdvacca
Differential Revision: D8886226
fbshipit-source-id: 82a489174efcda097887e70650a2038dc986d149
Summary:
@public
We need that because gonna add much more event-related stuff, so it deserves separate buck target.
Reviewed By: mdvacca
Differential Revision: D8831547
fbshipit-source-id: 616581b39b425a49302d5f7f86267e62b0d58389
