Tip: Processing values using lists

[Kyle Simpson]

Say you define an operation like:

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

Easy to use when you have two numbers, right? But what if you want to have a bunch of numbers that you add a single number to? You could:

var numbers = [3, 17, -4, 91, 11, 8, 0]; for (var i = 0; i < numbers.length; i++) { numbers[i] = sum( numbers[i], 42 ); } console.log(numbers); // [45, 59, 38, 133, 53, 50, 42]

But that's ugly and awfully imperative. Instead, we can use a built in method on arrays called `map(..)`:

var numbers = [3, 17, -4, 91, 11, 8, 0]; numbers = numbers.map(function(x){ return sum(x,42); }); console.log(numbers); // [45, 59, 38, 133, 53, 50, 42]

Cool!

But we can do better than that. Let's pull out that function expression:

function add42(x) { return sum(x,42); } numbers = numbers.map( add42 );

Notice how I only pass a reference to `add42`, but I don't call it like `add42()`. That's super important. `map(..)` will call `add42(..)` for us.

But, instead of defining that function manually, we could use another FP technique, closure, to make a utility that produces a composition on top of `sum(..)`:

function makeAdder(y) { return function(x) { return sum(x,y); }; } var add42 = makeAdder(42); numbers = numbers.map(add42);

The `makeAdder(..)` function makes and returns a new function. The new function that's returned is what we assign to the variable `add42`. That function has a closure over the variable `y`, which we pass in as `42`. It's then called by `map(..)` once for each value in the list, which will be the `x` parameter. Now that we have an `x` and a `y`, the `sum(x,y)` call computes the new value for each item in the list.

For our last trick, let's say we wanted to first add that `42` to all numbers in our list, and then sum all the numbers to get one big number. We can use another array method `reduce(..)` for that. `reduce(..)` takes a function similar to `map(..)`, but *that* function needs two values. The first parameter is the running total, and the second parameter is the current value in the list. In other words, it might be used like this:

var v = numbers.reduce(function(total,val){ return total + val; },0);

Also, look at that `0` as the second argument to `reduce(..)`. That's the initial value to start the reduction with. But does that function signature look familiar? It's exactly the same as the `sum(..)` we already defined. So we could just call `reduce( sum, 0 )`. Next, we'll observe that since `map(..)` is returning a new array, we can *chain* the `reduce(..)` call directly off the `map(..)` call. Putting all this together, we have:

function sum(x,y) { return x + y; } function makeAdder(y) { return function(x) { return sum(x,y); }; } var numbers = [3, 17, -4, 91, 11, 8, 0]; var add42 = makeAdder(42); var total = numbers.map(add42).reduce(sum,0); console.log(total); // 420

Processing values in lists is a lot more fun when we learn tools like `map(..)` and `reduce(..)`, and function closure. Happy coding!

[Peer Reynders]

While I immediately loved the fact that I could apply functional programming (FP) techniques in JavaScript but as a personal experience it became clear to me while working through Functional Programming in JavaScript with libraries such as lodash and ramda that ultimately JavaScript's imperative bits prevented me from ever getting into the mindset of thinking functionally. I am going to have to actively use a functional language to start thinking functionally - which initiated
my detour to Clojure(Script) (Elm would have been another option).

(def numbers '(3 17 -4 91 11 8 0)) ;; define a Clojure(Script) sequence named "numbers"

(def add42 (partial + 42))         ;; partial function application of the sum function '+' named 'add42'

(def total (->> numbers            ;; use the thread last macro to  
                (map add42)        ;; map over 'numbers' with 'add42' and  
                (reduce + 0)))     ;; reduce the resulting collection with '+'

(.log js/console total)            ;; 420

My ultimate hope is that this excursion will enable me to apply FP techniques much more effectively in the imperative space - "more effectively" than just picking up an FP trick here and there - though we all have to start somewhere. Interestingly is was the ever-growing JavaScript tooling pipeline that desensitized me to ClojureScript's upfront tooling - most of us use transpilers already to get tomorrow's JavaScript features in today's browsers; these transpilers will eventually output WebAssembly which will likely also be accompanied by a proliferation of client side languages. But for some time to come it will remain important to maintain a competent handle on JavaScript itself to be able to leverage the already existing and evolving codebase effectively.

[Kyle Simpson]

Yeah, JS is not actually a FP language. But I do think you can *think functionally* in parts of your program, which helps improve things, even if you don't have an entirely pure FP approach to all the code.

I taught a 3hr Frontend Masters course called "Functional-Lite Programming" which tries to sift through the bits of FP theory/concept that we can easily apply to JS without getting into all the terminology and dogma. I encourage devs to explore this more fully, as I've found that it really helps to be 50% FP than 0% -- 100% is not necessary to improve code.

https://frontendmasters.com/courses/functional-js-lite/