Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

see #264 Add Flux.doOnEach with Signal and individual consumers #288

Merged
merged 2 commits into from
Dec 8, 2016

Conversation

simonbasle
Copy link
Member

This is not the original ask from #264 but these doOnEach variants have value.

@codecov-io
Copy link

codecov-io commented Dec 7, 2016

Current coverage is 60.71% (diff: 100%)

Merging #288 into master will increase coverage by 0.44%

@@             master       #288   diff @@
==========================================
  Files           252        252           
  Lines         23207      24611   +1404   
  Methods           0          0           
  Messages          0          0           
  Branches       4235       4534    +299   
==========================================
+ Hits          13986      14942    +956   
- Misses         7425       7800    +375   
- Partials       1796       1869     +73   

Powered by Codecov. Last update e26aa57...dba0802

*/
public final Flux<T> doOnEach(Consumer<? super T> nextConsumer,
Consumer<? super Throwable> errorConsumer,
Runnable completeRunnable) {
Copy link
Contributor

@dfeist dfeist Dec 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO:

  • This isn't 100% required, using consecutive doOnNext() and doOnError() isn't particularly much more verbose.
  • If this method does exist i would either, limit it to next/error consumer only, or expand it to include afterTerminate runnable too so it has all signals.

}

/**
* Triggers side-effects when the {@link Flux} is subscribed, emits an item, fails
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really only for the advanced use cases. So if it is exposed, which I don't think is a bad idea, I would explicitly state in Javadoc that it is for advanced used cases and that generally the other more specific doOnXX should be used instead, else we risk people using this by accident and over-complicating things.

@dfeist
Copy link
Contributor

dfeist commented Dec 8, 2016

Looks good.

@simonbasle simonbasle merged commit e1b28e1 into master Dec 8, 2016
@simonbasle simonbasle deleted the 264-doOnEach branch December 8, 2016 17:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants