Lodash v3.0.0(lodash.com) |
Lodash v3.0.0(lodash.com) |
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');
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);
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 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]);
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
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 even tweeted to @jdalton on announcement "hey lodash, you're doing it right" :)
You probably shouldn't if you're in a hot path. LoDash actually outperforms some native ES5 features, Array#forEach being one of them IIRC.
A few years ago, sure, but these days I'd use es6-shim. The code will be shorter, have more documentation around the internet, and when old browsers die you won't have to change anything to be on standard JS.
http://filimanjaro.com/blog/2014/introducing-lazy-evaluation...
The _.chain() method furthermore gives a nice functional style ways of building lists which is useful when building UI in React, like so:
var list = _.chain([1, 2, 3, 4, 5])
.filter(function (value) {
return value > 2;
})
.map(function (value) {
return value;
});
console.log(list);
// prints:
// [3, 4, 5]Also your code was broken in Lodash 2 (it'd return a lodash object, not a list) and is more broken in Lodash 3 (chains are now lazy), so your code does just about nothing until you force the iterator's evaluation)
Over the last year Underscore has align more & more with lodash’s API so the need for a separate Underscore build has diminished. If you still need compatibility around some of the edges you should leverage modules in lodash v3 to supplement your Underscore use until the time you can drop Underscore completely.
Would mind posting an example?
(I was wondering what something like Flow.js would make of the code. i.e. Could it make catching those errors easier)
Cheers.
If you have code that looks like this:
var user_list =
fetch_json()
.then(function(data){
return data.users
})
var user_list =
fetch_json()
.then(get('users'))
The point where currying comes in is that it lets you define a single "get" function instead of a separate versions for one and two arguments:
//curried
x = get('users', data)
y = get('users')(data)
//non curried
x = get2('users', data)
y = get1('users')(data)
In the end the feeling I got was that trying to make JS more functional is not worth the trouble. If I could go back I would try to replace the promises with something less intrusive in terms of coding style, such as generators/coroutines.
Yes, I think I've come to the exactly same conclusions in the past, both with regard to promises and curried (or partially applied functions for that matter).
This may only apply to me but I've found that without strong, static typing to help out, my brain starts to melt sometimes trying to workout what heavily curried JS functions actual do without using a debugger.