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:
Previously, we used special JSI bindings method to release an event handler (`JSIReleaseFabricEventHandler`). Now we expose this ownership model as a regular `std::shared_ptr`, so when the owner got deallocated, the event handler will be released automatically.
Why not use `unique_ptr`? `unique_ptr` is faster (and simpler) indeed, but it does not provide `type erasure` functionality that we need; to use `unique_ptr` we would have to make JSI an explicit Fabric dependency (we will probably end up with it eventually, but I this particular case is not a good reason for that).
All interactions with `eventHandler_` are done in a non-owning manner, so it's as performant as unique_ptr anyway.
(Please ignore all changes in JSCFabricUIManager.h/cpp files, we will delete them soon.)
Reviewed By: mdvacca
Differential Revision: D9756732
fbshipit-source-id: bffdee0c724dc95855ced7c35e7c13cf1554796e
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
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: Unused loads hurt readability and take time to process.
Reviewed By: hramos
Differential Revision: D9494120
fbshipit-source-id: 455b56efadab1cb976344cffcb427772bfda2f71
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
Now, it's not just an abstract class, it's a regular class which unifies event delivery priorities using specific event beats and event pipe.
Reviewed By: mdvacca
Differential Revision: D8886232
fbshipit-source-id: c4360511e5fd477ca7407fc3ebbd99ca578e79cc
Summary:
@public
Instead of having two methods it's easier to have just one which can be abstracted as `EventPipe`.
Reviewed By: mdvacca
Differential Revision: D8886231
fbshipit-source-id: af9fd92dc4afa1219a11acce0aa021a85c94d232
Summary:
@public
EventQueue is a queue of events that synchronizing event dispatching with given Event Beat.
The only difference between UnbatchedEventQueue and BatchedEventQueue is that UnbatchedEventQueue `induce` an Event Beat right after enqueing an event.
Reviewed By: mdvacca
Differential Revision: D8886225
fbshipit-source-id: fedba6fdff2ecb6f3c615cea09b5fdaa58890479
Summary:
@public
EventBeat is an abstraction around proper event scheduling combining proper timing and proper threading. Event Queues use Event Beat to ensure that events are delivered on proper threads and in proper timing (probably batched). Consumers can `request` the next beat and `induce` immediatly beat.
MainRunLoopEventBeat implements particular Event Beat synchronized with the main event loop and calling a callback on the main thread.
Reviewed By: mdvacca
Differential Revision: D8886229
fbshipit-source-id: 1a42fcbf4cd61c6cb4c502890566c98b00226f31
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
