• Immutable.
• Stateless.
• Declarative.
• Pure.
• Compositions.
• Functions.

These are just a few things that come to one’s mind when thinking about functional programming.

In this post, I’m going to delve a bit deeper into the functional world and specifically, explore the awesomeness of currying and function compositions.

Currying

Currying is a way to partially apply arguments to a function.

Let’s start with the basics:

Here, our add function accepts two arguments and for it to actually do something, it needs both arguments to be supplied at the same time. It is possible, however, to apply just one argument and pass another later on in the application by returning a closure function like so:

and later on…

Though we have now lost the original functionality to pass both arguments at the same time, we can continue to add more arguments like so:

As it currently stands, it is impossible to pass just one function on a first call, and then the rest (3 in this case) together, afterwards.

This is where currying comes in. In theory:

• we want to create a function that accepts a function (our add in this case)
• then remembers the number of arguments it expects and returns a function that when called with nnumber arguments, will check if the number of arguments is >= the arguments that we’re expecting
• and if true, will then execute that original function with these arguments
• If not true, it will return another function that will accept some other arguments and when called, will concat the top arguments with these other arguments and loop back to this whole functionality again

A bit confusing? Let’s look at some code:

For a better understanding, I have named the inner functions. Let’s break this down by the following example:

Why is this useful? Well, we’ll get there, but let’s first look at some partial function applications we can start implementing straight away, like these two generic functions here:

Here are a few use cases:

Point-free

This seamlessly leads us to another concept that comes with currying: point-free programming.

Notice how our getName or getOnlineUsers functions don’t really say anything about the data they need? They just explain what they’re doing in a very descriptive, generic way. Thanks to currying we can completely get rid of the data part. But to achieve this, we strategically placed obj and arr as the last arguments accepted by our generic functions above.

If we had done this the other way around, we would just create some very unnecessary and useless wrapper functions, as you can see here:

The concern here, is that if you don’t specify the data in the arguments list, you might not understand what a function expects. This is why most functional programming languages have robust type systems.

But let’s not get off track.

Now that we’ve seen currying in action, let’s continue with the idea of point-free programming and start with implementing a map.

And to get the names of just online users:

By explicitly specifying what data our function expects, we’re no longer abiding by the rules of point-free programming.

This does however bring us to the next topic, function compositions.

Function compositions

There is a way to create these generic, descriptive functions, and to keep the data out of the way.

• First we create a function that will accept a n number of functions and return a new function, that will wait for the data
• Once called with data (n number of arguments), it will reduce on functions supplied, passing the result of one function, as an argument, to another, starting off with that initial data

This is what we’re trying to achieve:

We can see here that getOnlineUsers function is placed as a second argument, rather than run as a first step in our composition. This is because we’re following the same pattern as our daily coding – executing functions from right-to-left:

Let’s implement our compose function here:

We’re not done yet, however, as our reduce method will start with the very first function and do left-to-right computation, as it is now.

But before we fix that and make it right-to-left, let’s look at the reason why we’re breaking down our first batch of arguments into fn and fns. As we know, reduce method accepts only one argument as an initial data. But we need to be able to pass multiple arguments to our composed function, so fn will produce the initial data for our reducer here.

For example, if we do this (left-to-right computation):

Our reduce method would be confused, taking 1, 2, 0.3, 3.4 as initial arguments. We therefore let Math.max produce that initial data first.

Dilemma

Do we keep the left-to-right computation or switch to right-to-left instead?

Solution

Really, it comes down to whatever you find more readable, so why not have both versions?

And now going back to our initial issue, here is the full version:

But now, 90% of our code is just boilerplate. And this is where ramda comes in. In Ramda, every single function is automatically curried. So, if we were to re-implement this using Ramda, we would simply do:

Ramda vs. …?

Another lodash library, one might say. But no, Ramda specifically targets pure and functional programming concepts, meaning that not one of the functions here could have a side effect (like Math.random or debounce). There is however lodash-fp, which is similar to Ramda at first, but when you dig deeper, Ramda not only comes with loads of tiny utility functions, but also plays nicely with Monadic interfaces in JS, that will be covered in the next chapter.

Example 1: spread

Suppose we have an object and we need to take one of its properties and spread it at a current level:

desired result:

We can create a generic spread function like so:

‍

Example 2: reject and transform

Or perhaps we’re receiving an array of page objects from the server that look like this:

We want to reject the ones that are archived, and transform the rest with the following logic:

1. Make title uppercase
2. prepend //test.amido.com to the url
3. default active property to false if empty,
4. Increment meta -> views
5. default meta -> comments to 0 if empty

‍

episode 3: format user

We’ve just received a user object from one endpoint:

some posts array from another:

And we decided that we want to format the user in a very specific way – we want to merge firstName and lastName in a single fullName property and then add posts array to the user object under posts key.

Conclusion

Since an application, in functional programming, is just one big function consisting of tiny building block functions, in an ideal world, we could keep creating these function compositions and end up with just one big composition in the end.

However, there are some undefined and null monsters lurking in the shadows, that want to completely ruin our code execution and throw errors in the way. There are also side effects that need to be dealt with in a functional way. We can overcome these obstacles with the help of a few, beautiful monadic interfaces and keep composing the life. I will cover this in the next chapter.

P.S. There is a nice collection of recipes for Ramda to get you started: Ramda cookbook

‍