Allow listeners to stop an event's propagation - #127
mike-marcacci wants to merge 1 commit into
Conversation
|
Ya, sure thing! Because the emit method returns as soon as propagation is stopped, execution could actually end up being considerably faster when an early listener stops propagation; on the other hand, it does add an extra comparison to each successful if all listeners are processed as before. To me, it sounds like the current benchmark scripts should be able to cover these changes, unless I’m missing something. I’d be happy to add another benchmark if you can point me in the right direction. Here is a comparison of the current benchmarks run from both branches: stopPropagationEventEmitterHeatUp x 1,416,737 ops/sec ±0.71% (100 runs sampled) EventEmitterHeatUp x 1,294,572 ops/sec ±0.45% (100 runs sampled) EventEmitterHeatUp x 1,430,530 ops/sec ±0.56% (99 runs sampled) EventEmitterHeatUp x 1,420,539 ops/sec ±0.71% (98 runs sampled) masterEventEmitterHeatUp x 1,416,757 ops/sec ±0.76% (96 runs sampled) EventEmitterHeatUp x 1,382,359 ops/sec ±0.31% (99 runs sampled) EventEmitterHeatUp x 1,407,961 ops/sec ±1.34% (99 runs sampled) EventEmitterHeatUp x 1,273,150 ops/sec ±6.06% (87 runs sampled) |
|
@0x00A Do the bechmarks look good enough to you? |
|
This would be a nice addition. |
Replaces outdated PR EventEmitter2#127

While working on #126, I realized that it's currently not possible for listeners to stop the propagation of events, so I added it.
In my implementation, a listener can stop propagation by returning
false(compared with===). Tests and doc updates are included in the PR.Let me know if you have any thoughts about this either way.
Cheers,
Mike