Unclear which emitters need to be run() vs being live immediately

[tabatkins]

It's mentioned once in the docs that an ArrayEmitter doesn't send any values until it's run. (Not in the section on array emitters, tho.)

For other emitters this isn't clear to me - does an on emitter immediately start emitting events? All the examples using them seem to use run(), so maybe they wait until they're run to start doing so? This should be documented clearly for each emitter.

[pemrouz]

1. I'll review the new docs for Emitter.from to ensure we haven't missed any gaps in documenting when they start emitting values (generally all these should be lazy). As the canonical reference, I've also tried to ensure we don't duplicate explanations in different places, but rather link back to a single place.

2. This part of the proposal has evolved, but essentially on(object, 'event') will simply delegate to the Symbol.emitter on the object to create the Emitter. There's EventTarget and non-EventTarget-based API in the client, EventEmitter on the server, a million different libraries, as well as in-house solutions. This means those classes can implement it as they like, providing interoperability and people can write more portable abstractions/code once we have a language-level primitive.

   In that sense, it's not strictly for us to define it here, but a holistic approach is necessary hence why I've been discussing issues like these with @annevk and @mcollina. Even when there might be different preferences, and exact symmetry is not strictly necessary, everybody agrees platforms converging as much as possible is a good thing (less surprises for users).

   We haven't discussed this aspect in particular yet. However, I can confirm from experience that although I've always err'ed on the side of making things lazy, on has not been lazy and there have been no problems across lots of different use cases. All the examples use run() since it is a helper that makes several things more convenient (e.g. composing, returning the result, etc). The default run lifecycle callback is a noop so it's harmless to use both a vanilla Emitter (new Emitter) and those that do something more exotic there. So overall I'd be comfortable with both approaches and also don't think it's too significant. It may be theoretically better to make it lazy from one perspective. From another, it will theoretically align with other things: It matches the existing mental model people have for how these events work i.e. doing on(object, 'event').each(callback) to connect to multiple different subscribers, rather than being forced to get a new one each time, and remembering to run it. This is typically used as a means of conveyance throughout an application that decouples producers and consumers at both ends of the conveyor belt. For example, on(server, 'connected') and later emitting that event. Hence the default is to return a vanilla Emitter and it seems better for platforms and others to do the same thing, simplying calling .next(event) on the Emitter as they get it. My intuition would be to keep this as is unless we encounter some use cases that show benefits that outweighs the alternative .