Why I don’t recommend the Step module [node.js, npm]

Mar 17, 2013 in BLOG
javascript nodejs rant
3 min read

I prefer asyc to step. The async module has a cleaner interface, more options, and utilities. It’s a little beefier in size, but those things are beside the point.

Here’s why I don’t really like step. Tell me what you’d expect from this function:

var Step = require('step');

Step(
	function first(){
		console.log('first');
		
		this();
	},
	
	function second(){
		var x;
		console.log('second');
		if(!x){
			// do something that should set x
		}
		return x;
	},
	
	function third(){
		console.log('third');
	}
)

Did you guess:

$ node step-example.js 
first
second

If you’re not familiar with Step, you’ll probably look at that first function and wonder what this(); actually does. Well, it is actually shorthand for next(); (I’m simplifying a little here).

Assuming you’re at least somewhat familiar with asynchronous control flow, you could assume this(); calls the next function. But, what about the second function? It’s returning a value. Does that return from second, or from Step, or from some other function? It returns from second(), but… it passes the value to third. Or, it should. Unless x is undefined, in which case it will be considered an unchained function. Now, I don’t think your variables should regularly be ‘undefined’ at the point of return, but what if you use or someone on your team uses the popular convention of calling a callback as return callback(x);. If the Step module’s convention of tweaking this semantics is ignored, another developer may look at it as a typo, “You can’t call the context like that…” Right? Also, what if someone doesn’t understand the return value can’t be undefined and comments out the middle of that function? You may have cleanup logic that isn’t getting checked in third().

We’ve all seen that happen before.

In the above example, if x was not undefined, it would be passed as a parameter to third().

It’s this inconsistency which makes me feel like Step is an accident waiting to happen in a regular development team. The source code is pretty well written and concise. I think the author has done a great job, but the usage is unintuitive and I wouldn’t recommend using the module.

On the other hand, async is beautifully intuitive.

Consider this example:

var async = require('async');

async.series([
	function first(done){
		console.log('first');
		done(null, 'first');
	},
	function second(done){
		var x;
		console.log('second');
		if(!x){
			// do something that should set x
		}
		done(null, x);
	},
	function third(done){
		console.log('third');
		
		done(null, 'third');
	}
], function(err, results){
	console.log(results);
})

async.series allows us to run a series of tasks (functions defined within the array), which pass a value to the callback (that last function you see).

If you forget to pass a value, the results will contain undefined at the index of the array. Your third function won’t be skipped unless you forget to invoke the callback. To me, this is a pretty obvious error and one that is easy to spot and correct. Here’s is the output of the above call:

first
second
first
third
[ 'first', undefined, 'third' ]

To be fair, the example of Step acts more like a waterfall function. Here’s what that would look like in async.

async.waterfall([
	function first(done){
		console.log('first');
		done(null, 'first');
	},
	function second(val, done){
		var x;
		console.log('second has val: %j', val);
		if(!x){
			// do something that should set x
		}
		done(null, x);
	},
	function(val, done){
		console.log('third has val: %j', val);
		
		done(null, 'third');
	}
], function(err, val){
	console.log('callback has val: %j', val)
});

The above code is available on github: https://github.com/jimschubert/blogs

Related Articles