Functional Refactoring in JavaScript

in Too Much Detail

Yesterday, one of my colleagues asks me to help him to get the “functional” solution of a simple programming challenge: the advent of code day 2.

Edit: to be clear, that example is obviously overkill (and this is why it is subheaded “in too much detail”), but this is about the journey, not the goal :).

I don’t pretend to be an expert in functional programming, but I hope you’ll find interesting to have the different steps and thoughts that have guided me during this refactoring.

In this exercise, we have to compute the total surface area needed to wrap boxes (which have different sizes). Knowing the surface of one box is computed by the following formula (from the problem statement):

2*l*w + 2*w*h + 2*h*l + smallest side surface

And we will assume that our input has already been converted to an arrays list:

[ [l, w, h], [l, w, h], … ]

First let’s start with the classic procedural solution:

The first thing we notice is the accumulation through the total_surface variable, which is symptomatic of a missing reduce function:

Let’s extract each operation to its own function for a better separation of concerns:

I don’t really like the sides function because it does three times the same thing. It’s time to replace it with a recursive alternative:

Same mixed feelings with the content of the box_surface function, it looks like a reducer is missing:

Now we can delete the smallest_side function and put it in box_surface. And in the same time, remove the unnecessary parenthesis:

Since sides return an array, and box_surface make a reduction on it. We can extract the reduce instruction from the box_surface function:

Ok, but there is something we really love in the functional world: to have only pure expressions (that mean no { } characters to define lambda function’s body).

It is not possible here because box_side is used twice at line 9. So, let’s create a simple function apply to handle this:

We notice this apply function really looks like an IIFE:

At least, we can extract the boxes.reduce function (lines 7–8) and replace the box_surface function.

Now, we have only simple expressions to compute all the required steps:

Compare it with the original procedural code:

To be clear, this is not production code nor “best practice”. This is about solving a simple exercise with the most (to absurdity) functional idioms: only pure expressions and no duplications.

Of course, the readability is worst, but the idea was to show the thought process and the techniques involved.

You can follow me on twitter