I’ve been using lodash for a while at work, and I love having it in our toolbox. But, as I increasingly embrace composition of smaller functions as a helpful approach to building up the final version of an overall transformation of some piece of data, I’ve increasingly wanted to be using lodash-fp instead—those “auto-curried… data-last methods” are nice.
I could belabor the difference with words, but a code sample will do better. Here’s how I would write the same basic transformation in both Lodash and lodash-fp.
// Lodash const breakfasts = ['pancakes', 'waffles', 'french toast'] const uniqueLetters = _.flow([ bs => _.map(bs, words), _.flatten, bs => _.map(bs, b => split(b, '')), _.flatten, _.uniq, ls => _.sortBy(ls, id), ]) console.log(uniqueLetters(breakfasts))
That gets the job done, but wouldn’t it be nice if we didn’t have to have all those anonymous functions (lambdas) throughout?
// lodash-fp const uniqueLettersFp = _.flow([ _.map(words), _.flatten, _.map(split('')), _.flatten, _.uniq, _.sortBy(id), ]) const breakfasts = ['pancakes', 'waffles', 'french toast'] console.log(uniqueLettersFp(breakfasts))
Suddenly the intent is much clearer with the noise introduced by the lambdas gone. You get this because the lodash-fp functions are:
- auto-curried: that is, even though
_.splittakes the splitter and then a string, you can just write
_.split('')and get back a function which takes a string as an argument.
- data-last: because
_.splittakes the string to split last, it can be passed into an auto-curried function.
You need both to get that nice clean call to
_.flow. But once you have both, it’s really, really hard ever to go back, because it’s so much nicer for building pipelines of functions.
…I need to see if I can help do the work to make lodash-fp available in Ember.js.