Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Now that we have
each()
, you end up writing subscriptions more often than you use them. The idea behind subscribe() was that yielding directly to a stream to instantiate a subscription was confusing, which at first blush is still true.However, the decision to add a subscribe() method directly was made on the assumption that you would be using subscriptions by hand more often and so a little more
ceremony around authoring subscriptions was warranted.
That doesn't seem to hold anymore now that we have each() since it's almost always the
right thing to do instead of using to the subscription directly. The only case is when you're doing meta-level stuff in which case, understanding the underlying stream/subscription mechanics as a precursor is ok.
For example, adapting to this event emitter goes from:
to this:
Approach
Optimize for making streams easy to define