Allow accessing events registered via `vm.$on(...)` via a property, similar to `$listeners`

[tmorehouse]

What problem does this feature solve?

Currently, if an event is registered via vm.$on('event-name', handler), it does not appear in the this.$listeners object (Vue 2.6.x)

In some instances you only want to handle the event processing if there is indeed a listener registered (for performance reasons). But when component event listeners are registered programatically via this.$on (or vmReference.$on) it is not currently possible to see them in this.$listeners, e.g.:

if (this.$listeners['event-name']) {
  // Do something computationally intensive
  // then emit event
  this.$emit('event-name', resultOfComputation)
}

What does the proposed API look like?

No new API for the public.

[posva]

It makes sense not to have listeners registered via $on onto $listeners as those are usually passed via v-on by the parent and can be relayed to an element of the component with v-on="$listeners". It could be on a different object but why should this be added to Vue while it can be handled in user land easily by extending Vue.$prototype.on?

[tmorehouse]

The case is where the application dynamically adds a listener after the instance has initialized (and may remove it later).

And there doesn't appear to be any way to determine if a custom event listener has been added dynamically via vm.$on(...) (and when removed via vm.$off(...)).

In our use case, when a certain prop is set to true, the listener handler is instantiated on demand, and when the prop is false the listeners are removed.

I don't think modifying the prototype would help in this situation.

Adding a separate property would help if it isn't possible to place all the registered event listeners in the same object.

[tmorehouse]

I suppose we could check the private object vm._events, which does have the the listeners from both v-on and vm.$on(..) registered (and check the array length), but since that is not a "public" API it wouldn't be as clean.

[posva]

By modifying the prototype you could add those events to a custom property like $onListeners Eduardo San Martin Morote

…

On 15 Nov 2019, at 20:00, Troy Morehouse ***@***.***> wrote:  The case is where the application dynamically adds a listener after the instance has initialized (and may remove it later). And there doesn't appear to be any way to determine if a custom event listener has been added dynamically via vm.$on(...) (and when removed via vm.$off(...)). In our use case, when a certain prop is set to true, the listener handler is instantiated on demand, and when the prop is false the listeners are removed. I don't think modifying the prototype would help in this situation. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.