# Tidying Up a JavaScript Application with Higher-Order Functions

#### Posted on 5th January 2015 by Erin Swenson-Healey in Development

Higher-order functions are functions that can do one or both of the following:

1. Take a function or functions as arguments
2. Return a function as an argument

Most programmers by now are familiar with higher-order functions such as `map`, `reduce`, and `filter`. These functions abstract away the boilerplate when processing collections. For example…

Given a string-capitalizing function and an array of arrays of strings:

```function capitalize(s) {
return s.charAt(0).toUpperCase() + s.slice(1).toLowerCase();
}

var fruitsOfTheWorld = [
["apple", "pineapple", "pear"],
["manzana", "pera", "piña"],
["poma", "perera", "ananàs"]
];
```

…we can turn this:

```var results = [],
i = fruitsOfTheWorld.length;

while (i--) {
results.unshift([]);
var j = fruitsOfTheWorld[i].length;
while (j--) {
results[0].unshift(capitalize(fruitsOfTheWorld[i][j]));
}
}

return results;
```

…into this:

```return fruitsOfTheWorld.map(function(fruits) {
return fruits.map(capitalize);
});
```

In this post, I’ll demonstrate the usage of higher-order functions outside of a collection-processing context – with the ultimate goal of reducing boilerplate code in your real-world applications (as `filter` did above). We’ll start with partial function application (facilitated by Underscore’s `_.partial`) and move on to writing our own higher-order functions.

### What is Partial Function Application?

```function sum(x, y) {
return x + y;
}
```

Given the code above, partial application refers to the application of the function `sum` to between 0 and n-1 arguments, where n is equal to the number of parameters declared by the function. The result of partially applying a function to arguments is a new function with some (or none) of its parameters filled in with values:

```var sumWithXFixedToTen = _.partial(sum, 10);

(typeof sumWithXFixedToTen); // Function
```

The name `sumWithXFixedToTen` is bound to a new function returned by `_.partial` that behaves like `sum` – but where `x` will always be the value 10 (that is to say, `sumWithXFixedToTen(y)` equals `sum(10, y)` for all `y`). Moving forward, this new function can be fully-applied with just a single argument (since `sum` was already partially-applied to `10`).

```sumWithXFixedToTen(20); // 30
sumWithXFixedToTen(99); // 109
```

### Implementing Partial Function Application

To better understand what is going on behind-the-scenes of libraries like Underscore, we will now work through our own implementation of `partial`:

```function partial(fx) {
var firstArgs = Array.prototype.slice.call(arguments, 1);

return function fx2() {
var secondArgs = Array.prototype.slice.call(arguments, 0);
return fx.apply(null, firstArgs.concat(secondArgs));
};
}
```

Our higher-order `partial` function:

1. Takes as its first argument, a function `fx` to partially apply
2. Takes as its 2nd…n arguments (it is variadic), values to which `fx` will be partially applied (`firstArgs`)
3. Returns a new function `fx2` that, when called, returns the result of applying `fx` to the both `firstArgs` and `secondArgs`

This version of `partial` provides a convenient way of applying a function to some number of arguments – but lacks some of the nice features found in similar implementations provided by Underscore’s `partial` and `bind`, such as preservation of execution context and parameter-skipping. For the rest of this article, I’ll be using Underscore’s functions. For the curious, take a look at their implementation to see what ours is missing.

## Real-World Higher-Order Functions

### Eliminating Anonymous Function Expressions

When working with libraries like async, programmers often find themselves relying on function expressions to shim application code into the signatures required by `waterfall`, `series`, and the like. Partial application of async-agnostic functions to known arguments can eliminate the need for these shims, significantly reducing overall code volume.

For a concrete example, let’s take a look at some real-life client code I came across today:

```function createAccount(email, password, done) {
var id = uuid();

async.waterfall([
function(callback) {
},
function(accountId, callback) {
Services.Account.enable(email, accountId, callback);
}
],
function(err, auth) {
done(err, id, auth);
});
}
```

Using Underscore, we can eliminate the anonymous function expressions completely:

```function createAccount(email, password, done) {
var id = uuid();

async.waterfall([
],
_.partial(done, _, id, _));
}
```

Something to note about Underscore’s `partial` function is that it can accept a placeholder `_` which indicates that an argument should not be pre-filled – but rather provided at call time. In our example, the `done` function has had only its `id` parameter pre-filled, leaving `err` and `auth` to be provided once our series of asynchronous operations completes.

### Higher-Order Error Handling

A pet-peeve of mine is seeing Node.js-style error handling sprinkled all over a codebase:

```expressRouter.get("/api/ledgers/:id", function(req, res) {
UserService.getLedgerById(req.params.id, function(err, ledger) {
if (err) {
}
else {
res.status(200).json(ledger);
}
});
});

expressRouter.patch("/api/users/:id", function(req, res) {
UserService.getUserById(req.params.id, function(err, user) {
if (err) {
}
else {
UserService.updateUser(id, req.body, function(err, user) {
if (err) {
res.status(400).json({"message": "Invalid data provided"});
}
else {
res.status(200).json(user);
}
});
}
});
}
```

Notice a pattern here? In the asynchronously-executed callbacks that we provide for both `getUserById` and `updateUser`, we check the value bound to the first parameter of each callback (`err`) and respond with some error code and response if its value is truthy. This pattern of checking for and responding to errors can be abstracted into a higher-order function, leaving the application’s happy path free of crufty control logic.

```function ensure(notOkCode, notOkMessage, response, okFx) {
return function(err) {
if (err) {
response.status(notOkCode).json({"message": notOkMessage});
}
else {
okFx.apply(okFx, Array.prototype.slice.call(arguments, 1));
}
};
}

ensureValid = _.partial(ensure, 400, "Bad Request");

expressRouter.get("/api/ledgers/:id", function(req, res) {
UserService.getLedgerById(req.params.id, ensureFound(res, function(ledger) {
res.status(200).json(ledger);
}));
});

expressRouter.patch("/api/users/:id", function(req, res) {
UserService.getUserById(req.params.id, ensureFound(res, function(user) {
UserService.updateUser(user, req.body, ensureValid(res, function(updated) {
res.status(200).json(updated);
}));
}));
});
```

## Takeaways

Higher-order functions will help you write JavaScript with less cruft. By familiarizing yourself with Underscore’s `partial` function (or something you write yourself), you’ll have one more tool for factoring out common patterns into reusable, higher-order little chunks. Functional programming FTW!