See release notes and changelog: - https://github.com/lodash/lodash/releases/tag/3.0.0 - https://github.com/lodash/lodash/wiki/Changelog
I dig laziness, but why is `forEach` lazy? That's the only one that invokes immediately in libraries like Lazy.js.
Lodash v3.0.0
51–60 of 82 posts
Re: Lodash v3.0.0
#52Earlier quoted context omitted.
It's extra stuff that should be in the standard library but isn't. 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.
But if you want backward compatibility, you still probably want to use something like Lodash. I'd also argue that Lodash's/Underscore's interface is far better thought out than the standard library. The standard library has so many absurd gotchas, like `["2", "2", "2", "2"].map(parseInt)`. The verbosity of Javascripts lambdas also makes composition of simple parts more arcane looking than necessary, and having a whol…
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.
Re: Lodash v3.0.0
#53Re: Lodash v3.0.0
#54Q: "What does it do?" 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."
It's extra stuff that should be in the standard library but isn't. 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.
Re: Lodash v3.0.0
#55Earlier quoted context omitted.
I've been looking for some real-world examples of how currying might be useful in javascript. Haven't not used a language which supports currying for any real world project, I'm interested to know how it can help. 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?…
One situation where I felt compelled to use lots of currying was when I was working with a promise library for async code. There are lots of little callbacks you need to use and you benefit from having combinators that act as function versions of js operators, like "+", "[]" and so on and currying helps cut down on the number of combinators you need. That said, I didn't end up being a big fan of it in the end. Other…
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.
Re: Lodash v3.0.0
#56e.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...Re: Lodash v3.0.0
#57Earlier quoted context omitted.
Yes, you can. I've successfully done so in a Backbone/React app. 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]
That's not "furthermore". chain/value also exists in underscore. 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.
Re: Lodash v3.0.0
#58Whoah: "Tested in Chrome 39-40, Firefox 34-35, IE 6-11 , Opera 25-26, Safari 5-8"... 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.
Re: Lodash v3.0.0
#59Lodash is an incredible accomplishment, and having it vastly improves the Javascript authorship process over the standard library. 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.)
Re: Lodash v3.0.0
#60Earlier quoted context omitted.
One situation where I felt compelled to use lots of currying was when I was working with a promise library for async code. There are lots of little callbacks you need to use and you benefit from having combinators that act as function versions of js operators, like "+", "[]" and so on and currying helps cut down on the number of combinators you need. That said, I didn't end up being a big fan of it in the end. Other…
That sounds like an interesting approach. 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
})
You can write it more succinctly using a combinator library instead of writing the callback out by hand: var user_list =
fetch_json()
.then(get('users'))
Similar things also apply on other code that uses callbacks like maps, filters, etc. I also had combinators for other common JS operators (set, "+", "==", ...)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)
That said, there are some downsides to using combinators instead of writing the callbacks by hand. If you need to debug something the stack traces are harder to follow and currying doesn't play nice with functions like Array.prototype.forEach that pass "extra" parameters to the callbacks.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.