Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Add forEach as an alias to onValue #134

raimohanska opened this Issue · 4 comments

3 participants


Wouldn't it be nice to have methods similar to the Array API:

streamOrProperty.forEach(f [, thisArg]) calls the callback function f for all values of the stream/property. If a thisArg parameter is provided, it will be used as the this value for each invocation of f. If it is not provided, undefined is used instead.

The function f will be called with a single argument: the value of the stream/property event.

The function f will not be called for Error or End events.


I already tend to think of Observable.onValue as a "for each" operation, so this does make sense and seems a good addition.

It would also be nice, albeit probably not possible with useful semantics, to support CoffeeScript's list-comprehension syntax:

for event in stream
  doSomethingWith event

That would necessitate giving Observables a .length property and also allowing them to be indexed numerically, which may be inconvenient and nonsensical; in addition, this would only apply to any events currently in the stream and not all events ever emitted through the stream, which may render it in fact completely useless. Still, it's perhaps worth considering?


Streams do not have lengths and cannot be accessed using a numeric index, because they do not store the emitted event history anywhere. The only way you get to access all elements in the stream is using subscriber or helpers like onValue and possibly forEach.



I'm not a fan of forEach or each operations on FRP Events as it implies that we execute the callback for every element of the EventStream. This would not be true if we call forEach after the EventStream has already 'occurred'. Also, if you think about the effect of calling forEach on any other type of infinite Stream it would be an infinitely blocking operation (as we're not done until we've iterated through the whole stream).

onValue or something similar is nicer IMO as it is clearer what is actually happening.


Ok then, it might not make much sense to add more aliases for onValue, especially if they are misleading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.