A solution for stoping a flow after an early exit

[herobs]

There are a strong requirement that stop a flow normally instead of call callback with a fake err. I find a solution from restify:

You can pass in false to not error, but to stop the handler chain.

So only null to indicate a error, and false for normal terminal.

callback(false) will stop the flow, but won't active error handle like if (err) console.log(err).

[aearly]

Hmnn, this is very intriguing! I like that there is precedent in restify. It also seems like false might be a good value to use -- most people pass null or undefined. There is a bit of symmetry with how returning false in _.each also breaks the iteration.

[aearly]

@megawac What do you think about this?

[megawac]

Works for me (in a major bump) - would be nice for the createTester
implementation as it will have an improved method of terminating *Series
and *Limit based iteration

On Wed, Mar 30, 2016 at 2:58 PM, Alex Early notifications@github.com
wrote:

@megawac https://github.com/megawac What do you think about this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1064 (comment)

[aearly]

Yeah, I agree, we should save it for the next major. The breaking change we made with predicate-style functions (e.g. some, filter) would make this change cause extra confusion as people migrate since people would be passing false as the first arg.

[wilfredjonathanjames]

Not having this is very inconvenient. I support the use of cb(false) - it's what I had expected to exist when first using this module.

[megawac]

Think I will be hammering on some of these breaking changes over the weekend.

@hargasinski @aearly any thoughts on a 3.0 timeline? December perhaps?

[aearly]

Do we have any stats on how widely used v2 is? I wouldn't want to have more breaking changes for people to evaluate while most people still haven't upgraded.

[hargasinski]

We should probably do a minor 2.1 release with the changes applied in #1261 and a non-breaking fix for #1293 before 3.0. The docs will also get updated with the changes in PRs, such as #1263, #1271, and #1280, which will be helpful.

@aearly, that's good point. 2.0 will have been released for 6 months in December. Should we assume that will be enough time for most users to update? We could use the changelog to write a migration guide in the Wiki for 1.5 to 3.0.

[megawac]

This is now somewhat possible with 2.1.1 by returning async/internal/breakLoop

[stephent]

@megawac is there a link to any documentation for this (async/internal/breakLoop)? Not seeing anything on the site so far.

[aearly]

I'd be hesitant to use it, as we are not fully decided that this is how we want to handle early exits. We could change this later, breaking your code.

[aearly]

https://libraries.io has some great version stats: https://libraries.io/npm/async/usage

I broke down the percent of </> v2.x here 📈

20% of dependents are v2.0+. (v1.5.2 is our most widely used version, though, ~22%). v2.0 has been in the wild for a year. I think we can start thinking about v3.