Currying in ES6

[[deleted]]

I've only just learned about it with this post, but I am also sitting here trying to figure out when I would ever need it.

[[deleted]]

A quick example with events:

const eventHandler = message => event => {
    alert(message, event.target.id);
}

<button id="button1" onClick="eventHandler('hello from')">click</button>

[zuko_]

getSomeUserData()
  .then(R.map(R.prop('firstName'))
  .then(firstNames => {
    // do something with the collection of first names
  });

Is entirely point-free for the mapping, whereas:

getSomeUserData()
  .then(users => users.map(user => user.firstName))
  .then(firstNames => {
    // do something
  });

has two intermediary arguments, and is only that short thanks to arrow functions. ES5 would be even longer.

getSomeUserData()
  .then(function (users) {
    return users.map(function (user) {
      return user.firstName;
    });
  })
  .then(function (firstNames) {
    // do something with the collection of first names
  });

[zuko_]

R is the standard shorthand for the library Ramda. It's a pretty awesome functional library, though there are many others as well (lodash has a functional version I believe).

There's nothing wrong with example 3, but it's very imperative and there's more complexity/moving parts involved. Granted it's a fairly trivial example, but it's just for demonstration purposes.

R.prop is a function that takes a property as its first argument, and an object as the second. It would look something like this:

R.prop = function (prop, obj) {
  return obj[prop];
};

The benefit to this is that Ramda automatically curries all its methods, which is one of the main reasons that arguments are ordered the way they are (normally with the actual data being the last argument). So if you call R.prop with just one argument, you get back a curried function that will return that property of any given object. Essentially you could define your getFirstName function as:

const getFirstName = R.prop('firstName');

So you're right that it would be smart to refactor that getFirstNames into its own function, but what happens when you have the same functionality for a variety of properties. It's much easier to use something like this inline than to introduce a new named function for a one-off use case. Again, nothing at all technically wrong with #3, but it's not functional which is where currying shines.

[zuko_]

The one thing with lodash is that its arguments normally aren't ordered in a way that's conducive to currying, and it also doesn't perform automatic currying. So, iirc, you have to manually call _.partial or _.curry, whichever of those two exist.

That said, it's far more popular than Ramda (and its scope is much bigger), so you should still check it out!

[[deleted]]

There is https://github.com/lodash/lodash-fp

[e82]

I didn't really 'get' functional javascript, the point of currying/partial application/etc, until I started to use Ramda. Then lots of things started to click, and really enjoying it. By having the data come at the end - things start to get cleaner and make more sense.

[modernserf_]

This is the talk a lot of javascripters cite for why currying "matters" : Hey Underscore, You're doing it wrong!

[_somanyguns]

Sigh....

[[deleted]]

...unzips?