Welcome back to my series on practical functional programming in JavaScript. This time, I'll elaborate on a core functional programming concept that causes a lot of confusion for newcomers to functional programs: data last.

For the most comfortable read, you should have knowledge of Array.prototype.map and decent programming fundamentals.

Note: I use methods from my functional programming library rubico in a couple places to illustrate my points. I link documentation where applicable.

What is data last?

Data last is a programming convention wherein the data of a procedure is provided as the last parameter. This is in contrast to data first, where the data is the first parameter - you are probably more used to seeing this one.

This is data first. Quite literally, the Array (our data) is first.

[1, 2, 3, 4, 5].map(number => number * 2) // > [2, 4, 6, 8, 10]

This is data last. The Array (our data) is now last.

map(number => number * 2)([1, 2, 3, 4, 5]) // > [2, 4, 6, 8, 10]

map in this case is a partially applied function from rubico.

Documentation for map

Why does this matter?

Consider the program

const double = x => x * 2

const square = x => x * x

const doubleSquare = n => {
  const doubled = double(n)
  const squared = square(doubled)
  return squared
}

doubleSquare(3) // > 36

doubleSquare here is rather hand-holdy and imperative. However, since data is last for both double and square, we can rewrite doubleSquare using the functional approach in terms of just the two functions.

const double = x => x * 2

const square = x => x * x

const doubleSquare = pipe([
  double,
  square,
])

doubleSquare(3) // > 36

Documentation for pipe

Look ma, no variables! Data last allows us to write larger programs as compositions of smaller ones. This is a powerful concept for code reuse, and core to the functional programming paradigm. This idea is extensible at any scale; from small scripts to production workloads, anything you can represent with a function falls under this model.

I'll leave you today with a couple excerpts from the Unix philosophy:

Write programs that do one thing and do it well.
Write programs to work together.

We just discovered a powerful way for programs to work together via a simple convention: data last. Next time, we'll examine how we can consistently write programs that do one thing and do it well. Be on the lookout for Side Effects and Purity.

Edit: You can find the rest of the series on rubico's awesome resources