Trailing emitters are inconsistent between sequencing before or after operator

[tabatkins]

All the "transformation" emitters like map() treat trailing args as a composed emitter before themselves: map(fn, ...emitters) == compose(...emitters, map(fn)).

But on()'s trailing arguments are composed after itself: on(el, name, ...emitters) appears to be equal to compose(on(el, name), ...emitters).

I get why on() obviously can't sequence its trailing emitters before itself (because it's purely a source of values, not a transformer), but the inconsistency grates. I'd prefer this case just explicitly require a .each() rather than taking trailing emitters.

As far as I can tell, only on and once act like this.

[pemrouz]

Firstly, I'm super-impressed how you read everything and managed to get all this nuance just from my terrible docs given we didn't have time to go through it together in depth!

In short, I fully agree with you here :). More background: It's not symmetrical in relation to the operators, but it was a natural extrapolation along another axis. Namely, going from existing callback code to connecting a stream of events to something else is conceptually and implementation-wise exactly the same:

on(object, 'event', callback)
on(object, 'event').each(callback)

This makes it really easy to teach and for people to adopt/upgrade their code. And since .each actually takes multiple arguments, we just pass it the multiple arguments.

on(object, 'event', ...args)
on(object, 'event').each(...args)

However, as it turns out, albeit more general, empirically this is not used at all so I'm happy to drop it.

More importantly here though, in discussion with @smaug---- he reminded me about the capture phase with regards to EventTarget integration, so we'd need to reserve the last parameter for an options object. Since the event name and optional options object will all instead be simply delegated to the Symbol.emitter implemented on the object class to handle and vend a new Emitter, it would then require some cognitive overhead in remembering the order of parameters and hence become more confusing than it's worth. In that regard, on/once will no longer handle any composing or connecting, simply just be responsible for creating an Emitter from existing objects, as you also mentioned.