Spec the forEach() operator

[domfarolino]

Prototype Chromium implementation (with WPTs): https://chromium-review.googlesource.com/c/chromium/src/+/5249869.

---

Preview | Diff

[domfarolino]

Feel free to take a look @keithamus, if you're interested. But no pressure.

[keithamus]

This one LGTM 👍

[keithamus]

This seems generally useful but I'm curious if there was any discussion weighing up why this should return a promise, vs undefined per Array#forEach, or if this should perhaps be renamed to differentiate itself from any symmetry of the array equivalent?

[domfarolino]

I think the analogy is that this kind of since array iteration is synchronous and returns undefined when done, therefore Observable "iteration" (i.e., forEach()) would return a Promise<undefined>, since that will tell you when Observable "iteration" is is done (since it is asynchronous). That kind of timing information could be useful.

There is some discussion about this on #69, but basically I'm not sure there is much utility in any operator returning undefined ever, vs Promise<undefined> which carries strictly more information. But I'd be open to re-consideration if you want to strike up more conversation or file another issue.

[keithamus]

I don't want to rock the boat on what is likely well-thought out and a culmination of very long discussions, but having said that, part of me wonders if this is a little awkward and maybe it's just... not worth implementing forEach at all? I wonder how much value it adds. Presumably given how much of this is modeled on existing user-land libraries we can find some kind of usage figures to guide us on which API should be prioritized? Is forEach high in that list?

[keithamus]

I'm sure you have an answer for the above so I filed #106 to hopefully document that!

[domfarolino]

As an individual operator, yeah I think forEach() is useful. If we don't provide it, people will basically just try and use map() in a non-idiomatic way to do the same thing, like this example which I think is an accurate portrayal of what would come, absent this operator: whatwg/dom#544 (comment).

Secondary to the utility, it provides parity with the Iterator helpers proposal which I think kinda backs up the utility argument, and makes things a bit more symmetrical.

This operator is kinda somewhat similar to https://rxjs.dev/api/operators/tap which is a really popular operator, although admittedly it is different in that it doesn't return an Observable. But you brought this point up in 2019 anyways, which seems reasonable.

In short, I think the operator is useful, however I'm open to discussing what it should return. The existing momentum points to Promise<undefined> but if we want to have further discussion I'm fine with that too.

[domfarolino]

The Chromium implementation for this has landed with tests, so I'll merge this.