From Closures to Curry and Compose

Bruno Pineda
sngular-devs
Published in
5 min readDec 11, 2018

First steps to understand one of FP features

Early steps on the way…

In the last serie, that I wrote “Comprende JS”, we talk about JavaScript fundamentals, one of these is understand “Closures” and one reason to use it and show their power.

So, if you don’t know, what is a “Closure” in JS, here is the chapter of the serie, this is in spanish, but is very detailed.

Why are the “Closures” powerful?

Well, in the “Closures” chapter, I told that understanding of this feature, by default will give us a powerful tool to use it, then now we will talk about Why is powerful tool.

Do you remember that when a closure is active, is because a function executed have inside, another function declarated, right? and when this happen in somewhere place in memory, the function’s lexical and variable environment is alive, even when the execution context of these function is gone from execution stack, so… the power is this part just when in memory are placed these declarations, let’s view one code example.

This example is the basic case of closure, while the id declaration is in the parent function context, the inner function is using it… kids stuff right?, but to show the power of this, we need understand one case of use…

Currying

First, the “Curry” term is because of Haskell Curry, yes, Haskell the Haskell language creator, if you don’t know what the fuck is that, is a powerful functional language, here is the official page for more info.

Well after the ad’s cut, we continue, so… when we talk about Currying, is the way of resolve the inputs and outputs of one function, let’s view an example of a function not curried vs one curried.

This is a not curried example, since, the inputs are taken from one function only, I mean, the params a, b and c are in the same function params getResult(a, b, c), this is the traditional and imperative way of write a function, but let’s see a curried example.

Well see that, the first difference with not curried, is that curry use Closures feature, and for this is powerful, since, if we use a closure we can avoid repeat code, example.

We supose that we have many operations to do, but all are sums and we need the same sum but diferent multiplicator like this.

See that, while in traditional not curried way, we repeat the a and b params, in the curried way just resolve and set in the closure memory the result of sum to just to put the c param in each case.

But, if this is not enough for you, we will see how we improve the declarative way to imperative way, with…

Arrow functions as declarative helper

When we talk about declarative and imperative, we refer to the way of write code, statements and more, since, the declarative way implies use of statements like if, function, switch, for, etc, while in the imperative is characterized by don’t use it, and the word function is a statement, so, we need remove it and replace it by arrow functions like this.

If we compare both ways…

And if we compare the curried declarative way vs not curried imperative…

Just one line in declarative way, nice right?, but we go to apply more action to this, we go to write a function that iterate with a map, one array.

For this, I introduce you to…

The Good, the bad and the ugly

But we go to start with…

The ugly way

In this way, we can see that we use a function statement map, to return new array from .map() method and the callback to this method is a function declarated on the fly, such function, returns for each number of the array multiplied by 2, the first problem with this, is lack of sequence and this refence problem, check this article for more info, also if we want reuse this double function and apply in other function, we have declare it in each function.

In addition, we use imperative way and we write 8 code lines, ugly right?

The bad way

In this case, we improve the previous implementation, since, we have separated the callback function double() and this allows reuse in other function, but we have nine code lines and we keep the declarative way yet.

The good way

Nice…First we have a full declarative way, second, we write just four code lines and we never lost the main context and the sequence is the same.

This is a easy case, but imagine that we have an array of objects and we want first, filtered list with one criteria and after we want apply to these filtered list one modification in their properties, well, let’s see the imperative and ugly example.

The ugly way

Why ugly?, first, we have a non reusable code, second we have chaining methods, the chaining methods generate for each iteration two new arrays one from filter() and other from map() method.

So, if we want another filtered list but diferent criteria, we have repeat all code, since, the callbacks are declarated on the fly.

The bad way

Well, in this case, we improve the usability, since the where and applier callback are separated and these can be reused in another map() and filter() methods, but sacrificing the number of code lines and keep the chaining methods memory leak problem.

The good way

With this way, we have a full declarative mode and we are applying the currying and function composition, also, the reusability is available with seven or less code lines.

But, we can improve this?…Yes, we let’s introduce to…

Compose

Maybe this is known to you if you comes from Redux on React, something like this.

const store = createStore(
reducer,
compose(
applyMiddleware(thunk),
DevTools.instrument()
)
)

Like Redux compose() will allow us combine functions where the result of the first function will be the arguments to the next function, a kind of chaining without the dot problem.

It is worth mentioning that compose() is a utility from Funtional Programming (FP), and Redux use it by convenience.

Now, in our case we go use compose() to combine map() and filter() methods and this way, we can get a legible and elegant way to write in declarative mode.

That said, let’s look the next code, retaking the previous example.

Ok, this example is without compose yet, just applying curry and function composition and this is good, but we can improve this with compose like this.

Where fns are the functions to combine through .reduceRight() method, and x is the initial value for the first call of .reduceRight() method that in this case is the items before apply the filter.

Reduce allows me execute each function through previous value and current value and the x value is passed to reduce method to apply the initial value.

Now I show you the complete code with full declarative way, with curry, function composition and compose.

Note: Number of lines implies also documentation.

First approaches to FP

Functional programming is a programming paradigm, that in Javascript is powerful by their “Closures” usage adventage, this we could be the first approach to FP, if you comes from OOP.

The next steps are the understanding of FP, I recommend the serie called Composition software by Eric Elliot.

Conclusion

Finally we could see the big difference between learn and understand “Closures” and why are powerful, remember…

There are no borders to learn, those you create.

--

--