I prefer Ramda to Lodash and Underscore. It has a lot of functions that are missing in vanilla JS.
You might dig
Lists of JavaScript methods which you can use natively
101–110 of 162 posts
Re: Lists of JavaScript methods which you can use natively
#102Earlier quoted context omitted.
> if you don't mind throwing an exception when given invalid input such as null or undefined That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.
Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.
Sure, we can always make up an examples.
Perhaps if you are using null to represent something explicitly in your data. But silently failing on undefined is just going to lead to an other bug somewhere else entirely and half a day of debugging.
I would much rather fail early and loudly than having to hunt down some anecdotal bug that happens every prime-th national holiday and is impossible to reproduce.
Re: Lists of JavaScript methods which you can use natively
#103Earlier quoted context omitted.
Don't miss the forest for the trees. Re-implementing _.forEach, _.map, and _.reduce to do something like loop over objects yourself is going to most likely end up taking more code than just using those functions from lodash. Not to mention that you most likely won't have the same amount of testing, speed/optimization, or "familiarity" across devs with a home-grown solution. Yeah, don't pull in lodash if you are makin…
I do not agree at all. What is so hard about for loops? I do not agree that using the native-to-the-platform looping constructs will create as much code as half a megabyte. I'm looking at it right now: the full build of Lodash is 503KB. That's also half-a-meg of code that needs to be parsed by the JS engine. And nothing else you said has anything to do with site performance. Do users care if it took you 10 seconds ve…
The kitchen sink size of Lodash is ~22kb gzipped, the core build is ~4kb gzipped, and it's modular so you can cherry-pick what you want
Re: Lists of JavaScript methods which you can use natively
#104Earlier quoted context omitted.
> if you don't mind throwing an exception when given invalid input such as null or undefined That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.
Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.
Seriously. A really common example, ever have a website that completely fails to load when you're running adblock? Would you rather have a blank page, or a 99% functional website with a couple of error messages in the console?
Re: Lists of JavaScript methods which you can use natively
#105Earlier quoted context omitted.
Actually, a full version of loadash is not insignificant.
You might dig https://github.com/lodash/lodash-webpack-plugin
We do plenty fine with just `import get from 'lodash/get', however we're fairly eager to upgrade to webpack to to take advantage of it's tree-shaking capabilities.
Re: Lists of JavaScript methods which you can use natively
#106A nice thing Lodash has that Native doesn't is the 'matches' shorthand for things like find. I find it easier to read and quicker to write than a callback.
_.find(items, {id: 10});Re: Lists of JavaScript methods which you can use natively
#107Earlier quoted context omitted.
Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.
Sure, we can always make up an examples. Perhaps if you are using null to represent something explicitly in your data. But silently failing on undefined is just going to lead to an other bug somewhere else entirely and half a day of debugging. I would much rather fail early and loudly than having to hunt down some anecdotal bug that happens every prime-th national holiday and is impossible to reproduce.
For client-side webapps? Users are just going to hit reload and move on. For just about every website I can imagine, if your two options are to leave an extremely rare bug that's impossible to reproduce, or to effectively take the website down for all users, the former is the unambiguous right choice.
Re: Lists of JavaScript methods which you can use natively
#108Earlier quoted context omitted.
> if you don't mind throwing an exception when given invalid input such as null or undefined That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.
Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.
Catch the exception and pass.
It's why I like python's attitude toward this. It's explicit, not implicit and therefore easier to read and maintain.
Re: Lists of JavaScript methods which you can use natively
#109Earlier quoted context omitted.
I skipped over it because it's a solution in search of a problem. I think developers should be expected to understand the native constructs of the language they use. You previously also talked about "being more familiar to onboarding developers". Why should Lodash be more familiar than the native looping constructs to anyone? Why would Lodash be more familiar to a developer you're onboarding who is more used to some…
>You had to take time to look up operator-in because you're not used to using operator-in I'm using in (`if('age' in value)`), but not for..in. There's a difference. I don't need to use that (you didn't in your example, even though you should have), but then my code would blow up in many of the same cases as yours will. Anyway, what's wrong with that code is you'll need a hasOwnProperty check, you'll need to break ou…
> it blows up if 'age' isn't a property on one of the objects in the object
No it doesn't. It will return as undefined, which evaluates to false when compared to 1 using either triple- or double-equals.
And why call hasOwnProperty here? I'm pretty sure I want to know the age of any properties inherited into my object from a superclass.
At worst, I will grant you an undefined/null check:
var val = null;
for(var k in obj){
if(obj[k] && obj[k].age === 1){
val = obj[k];
break;
}
}
Re: Lists of JavaScript methods which you can use natively
#110Earlier quoted context omitted.
I skipped over it because it's a solution in search of a problem. I think developers should be expected to understand the native constructs of the language they use. You previously also talked about "being more familiar to onboarding developers". Why should Lodash be more familiar than the native looping constructs to anyone? Why would Lodash be more familiar to a developer you're onboarding who is more used to some…
>You had to take time to look up operator-in because you're not used to using operator-in I'm using in (`if('age' in value)`), but not for..in. There's a difference. I don't need to use that (you didn't in your example, even though you should have), but then my code would blow up in many of the same cases as yours will. Anyway, what's wrong with that code is you'll need a hasOwnProperty check, you'll need to break ou…
[deleted]