Commit Graph

9 Commits

Author SHA1 Message Date
Daniele Conti 08c404d293 Eagerly change the listeners count
Summary:
While working with `RCTEventEmitter` I noticed that if an event is emitted before `_listenerCount` is updated, it will not go through because the listeners count hasn't been updated. Moving the count update before the invokation of `startObserving` and `stopObserving` fixes the issue. Same way if you remove the last listener and an event is fired before the count is updated (while it shouldn't be fired).

**Test plan (required)**

An easy test to demonstrate it is to implement `startObserving` to synchronously fire an event. Without the change, a warning is thrown, with the change, the event is fired. Not very strong on Obj-C here and I didn't know how to mock out the native stuff. Would be glad to write a failing unit test tho :)
Closes https://github.com/facebook/react-native/pull/11907

Differential Revision: D4738965

Pulled By: javache

fbshipit-source-id: cf175051be5b9c5de761d3dcd290560e1639b05e
2017-03-20 12:49:00 -07:00
Pieter De Baets e762d961cd Use new enqueueJSCall method everywhere
Reviewed By: majak

Differential Revision: D3605263

fbshipit-source-id: 215f896d675b937593c8b796ed6ec5261ac74dbf
2016-08-02 11:14:06 -07:00
Nick Lockwood b71db11554 Update RCTNetworking, RCTNetInfo and RCTLocationManager to use new events system
Summary: Updated networking and geolocation to use the new events system.

Reviewed By: bestander

Differential Revision: D3346129

fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
2016-05-25 04:28:36 -07:00
Konstantin Raev 2de0323182 Reverted commit D3339945
Summary: Updated networking and geolocation to use the new events system.

Reviewed By: javache

Differential Revision: D3339945

fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
2016-05-24 12:43:30 -07:00
Nick Lockwood 3f08fe4b7f Update RCTNetworking, RCTNetInfo and RCTLocationManager to use new events system
Summary: Updated networking and geolocation to use the new events system.

Reviewed By: javache

Differential Revision: D3339945

fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
2016-05-24 10:29:00 -07:00
Nick Lockwood d9737571c4 Updated AppState module to use new emitter system
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.

Reviewed By: javache

Differential Revision: D3310488

fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
2016-05-23 09:13:37 -07:00
Nick Lockwood 516bf7bd94 Fixed NativeEventListener deregistration
Summary:
The `EmitterSubscription.remove()` method was previously calling `this.subscriber.removeSubscription(this)` directly, bypassing the mechanism in `NativeEventEmitter` that keeps track of the number of subscriptions.

This meant that native event modules (subclasses of `RCTEventEmitter`) would keep sending events even after all the listeners had been removed. This wasn't a huge overhead, since these modules are singletons and only send one message over the bridge per event, regardless of the number of listeners, but it's still undesirable.

This fixes the problem by routing the `EmitterSubscription.remove()` method through the `EventEmitter` so that `NativeEventEmitter` can apply the additional native calls.

I've also improved the architecture so that each `NativeEventEmitter` uses its own `EventEmitter`, but they currently all still share the same `EventSubscriptionVendor` so that legacy code which registers events via `RCTDeviceEventEmitter` still works.

Reviewed By: vjeux

Differential Revision: D3292361

fbshipit-source-id: d60e881d50351523d2112473703bea826641cdef
2016-05-16 04:13:56 -07:00
Nick Lockwood 2525feb37f Updated Websocket to use new event system
Reviewed By: javache

Differential Revision: D3292473

fbshipit-source-id: f9a9e0a1b5a12f7fa8b36ebdba88405370f91c54
2016-05-12 08:30:24 -07:00
Nick Lockwood 9ee1f37bad Added native event emitter
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/

I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).

Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.

JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:

    const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
    RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });

You'd now write:

    const Keyboard = require('Keyboard');
    Keyboard.addListener('keyboardWillShow', (event) => { ... });

Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:

     this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);

Write:

    this.addListenerOn(Keyboard, 'keyboardWillShow', ...);

This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.

As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.

For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.

Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).

Reviewed By: javache

Differential Revision: D3269966

fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
2016-05-11 06:27:29 -07:00