In the last few weeks – with the help of everyone in the WatchMeCode community slack – I’ve found a places where currying seems to be beneficial. One of those places is a replacement for a function’s .bind method.
What Does .bind Do?
In this example, I have a basic add function on which I call the .bind method. The first parameter – undefined, in this case – sets the value of “this”. The second parameter – 1 – sets the first argument that will be passed to the function when it is finally executed.
The result of the .bind call is a new function. When I call this function, it only needs 1 parameter to execute.
The general term for what just happens is “partial functional application”. That is, the function was partially applied with the .bind call to set the context and the first parameter.
The final execution of the function didn’t happen until later, when I invoked the function, passing in one more argument in this case.
This is a common pattern – I’ve used partial function application in a lot of code, over the years. But now, with currying in my tool belt, I see less need for this.
Currying The Add Function
With currying, we can get the same effect as the partial function application from above, but without using the .bind method. The intermediate steps, though, provide much more flexibility than .bind does.
Let’s take the same add function, and manually curry it, as I showed in my video on the basics of currying.
In this example, there are 2 functions. The first function, add, takes a single parameter and returns the second function. The second function also takes a single parameter and then executes the addition, returning the result.
Both the .bind code above, and this code, show an “add1” method that is the result of the first operation. The both show the resulting function taking a single, second parameter to perform the calculation, as well.
I have effective produced the result of partial function application, using currying instead of .bind.
So, what’s the real difference? Is currying better than .bind? Why?
A Functional Alternative
For the simple comparison above, there is very little in benefit to using currying vs .bind.
But there are 2 major improvements that currying offers over .bind.
- I don’t have to specify the context (“undefined”, in that example) when currying
- Currying can reduce the code by not chaining function calls
While you can .bind any function – including an already partially applied function – you end up with some rather ugly code with the .bind littered everywhere.
This example shows how you’re required to continuously pass the context parameter to the .bind call, even though it’s never being used.
The currying alternative gives you slightly less code, as well:
Here, the code is a little more succinct. The use of ramda’s curry method allows you to curry the same function that was previously used.
If you’re wondering about supplying multiple parameters, though, both the .bind and curried version can do that:
There’s very little difference in this code, when it comes down to it. Do you want to supply the “undefined” parameter, or add extra parenthesis?
All this of this leads to the question…
Is Currying Better?
I don’t know if currying is “better” or “worse” or even “more flexible” than partial function application – at least not in these examples.
I think they can largely be interchanged, based on what you’re more comfortable using.
However, currying gives you options for additional functional programming tools and techniques.
From what little I know of functional code, it is common for composition, mapping and other tools to require functions only take a single argument. And in these examples, currying would likely be the choice to make it happen – though I bet you could make it work with .bind, as well.
For now, at least, I can say that currying does provide a functional alternative to the .bind method. And, frankly, I find it easier read the curried version of my code, when compared to .bind calls everywhere.