The lodash & lodash-compat npm packages now come with modules baked in too.
Perfect for Browserify!
// load the modern build
var _ = require('lodash');
// or a method category
var array = require('lodash/array');
// or a method
var chunk = require('lodash/array/chunk');
This is great. It combines trust and quality with modularity.I found a page [1] which talks about currying in javascript, then says "Are there practical uses for currying in JavaScript? Not really."
Can you point me at anything which will help me see why it's useful?
[1] http://benalman.com/news/2012/09/partial-application-in-java...
var predicateListFunc = function(props) { return R.allPredicates(R.map(R.curry(R.eqProps), props)); }
var compareProperties = R.unapply(predicateListFunc);
var mergeLists = R.unionWith(compareProperties("Property1", "Property2"));
var groupById = R.groupBy(R.prop("Property1"));
var getGroups = R.compose(R.toPairs, groupById, mergeLists);
var groups = getGroups(list1, list2);
With this code I can merge any two lists (list1 and list2) on any two properties (Property1 and Property2), and then group the result. I use this to synchronize client and server data.I don't know if this answers your question, since I wrote in about an hour of learning Ramda.js, and there might be an easier way of doing it.
Here's a fiddle:
I've linked to the slides on currying but you'll need to back up to follow the whole example.
[1] http://scott.sauyet.com/Javascript/Talk/FunctionalProgrammin...
That said, I didn't end up being a big fan of it in the end. Other people can get confused by the new abstractions the combinators introduce and whenever you pass the wrong number of arguments to a function you end up with very tricky runtime errors (this isn't an issue in Haskell because the type system checks this for you)
A: "A utility library delivering consistency, modularity, performance, & extras."
Q: "Yeah, but what does it do?"
A: "Oh, nothing but it does it consistently, modularly and performant. We also have functions for string handling in the extras module."
These days, a lot of it is actually in the standard library - for example, array maps - and invoking lodash just calls the es5/es6 built in, with a slightly uglier syntax.
I think the most useful functions are the typechecking utilities (typeof in javascript is the most useless keyword the human kind engineered in a language).
In the end is a very nice library to work with when it does not get in the way (of course, if you are using `_.each([], fn)`, you should think again and use `Array#forEach` or a nice `for`)
I always appreciate it when the top of the project page provides a one-liner explaining just what it is I'm looking at.
I probably should have guessed, but I hate guessing wrong and missing out on something I could really use.
In a nutshell it's a collection of functions that work on arrays,objects and functions.It's a toolbox.
That being said, I still can't believe we don't have a flatMap:
https://github.com/lodash/lodash/issues/812 https://github.com/jashkenas/underscore/issues/452 (Underscore repo, but still Mr. Dalton, author of Lodash, opposing.)
It's also under active maintenance from an enthusiastic dev. Do your own research, but I go with lodash.
e.g.
expect(_([1,1,1,1,2,2,3,4,5,6,6]).distinct().conj(7).out()).toEqual([1,2,3,4,5,6,7]);
Here's a small set of specs showing early ideas https://github.com/swannodette/mori/blob/8e82b15b35b2989d4a2...Substack wrote an article [1] explaining some of the problems that monolithic libraries cause in an ecosystem.
IE6+ support! I wonder if that's real, full support, or more like a "there are serious bugs we'll probably never fix for old IE".
Working with old IE versions is loathsome (but still required for some of us), so libraries that just work there are much appreciated.
Seems like no one cares. Strange.
I did click -- but only because a previous comment made it seem like Lodash was something related to functional programming. If it hadn't been for that comment, I have ignored the post, because I wouldn't have had a clue WTH Lodash was.
Now, sure, people who've already used or heard of Lodash are going to know, but they're probably already following it on Github. :-) The unwashed masses like me won't have any idea.
I guess the key here is to try to make the title give some indication of what the thing is.
[edit] Changelog is there https://github.com/lodash/lodash/wiki/Changelog
Some decisions sound really weird, such as the fact that forEach is now lazy. It is not a standard replacement anymore, and probably break the compatibility for quite a few apps (even if I'm deeply convinced that we should all use the native functions and shim them when needed).
// in 2.4.1
_([1, 2, 3]).forEach(function(n) { console.log(n); });
// => logs each value from left to right and returns the lodash wrapper
// in 3.0.0
_([1, 2, 3]).forEach(function(n) { console.log(n); });
// => returns the lodash wrapper without logging until `value` is called
_([1, 2, 3]).forEach(function(n) { console.log(n); }).value();
// => logs each value from left to right and returns the array
Seems that the only apps this change will break are those who are using side effects in a chain. Which is a pretty dubious choice, IMO. Especially given that Lodash is a "functional programming library".