Lodash is a Javascript utility library, that helps you work with arrays, objects, strings, and just write fewer functions in general. Let's talk Lo...
For further actions, you may consider blocking this person and/or reporting abuse
I'm confused - most, if not all of the examples above can be achieved using less code in plain JS - without the overhead of a library. Using plain JS will also be faster. The debounce one is quite useful, but again - easy to write yourself instead of including a whole library
1.
2.
3.
4.
No 72.5Kb of
lodasheven remotely requiredIn general for this simple cases yes you don't need lodash, but in more real complex applications is simplify many things especially the chaining.
For example in 1 and 4 when you don't know in compile time the "path", but is something that is user/api/external input how you are going to do it ?
One other thing that I like in lodash is the internal error checking and handling. For example the 2 and 3 example if the adoptableDogs is null/undefined the code is going to get exception, you need to check it before use it.
The lodash is going to return empty array in map and null in find, a consistent result that you don't need to have special check or path in your code flow.
I agree. I was merely pointing out that these were poor examples, that do not really give any idea of why, and in what situations Lodash can be beneficial
Some points:
setsafely gives you a new object (not deep clone, but property copy)Promise, your own composition, or the new pipeline operator, you end up wrapping all this stuff.So, the writer's example for number 4 then does not even work? The way the example is written implies mutation. This adds even more weight to my contention that these are poor Lodash examples
No it works, he imported map form lodash, not lodash/fp. Most people when starting to learn will start with Lodash, and that works great for many years. Those who want curry first, data last style coding can use lodash/fp when they are ready (if they want, no pressure). All the same imports, but the parameter order is usually reversed.
Ah ok, your comments were referencing a functional version of Lodash
Sort of, it's kind of confusing and frustrating.
Like, Lodash makes it pretty clear some methods mutate the original Array/Object, while others return shallow copies. You'd assume the FP version would, but that's not always the case, so... it's kind of FP, which is better than nothing; at least they document it.
For things like
set, though, thankfully, they work the same in both lodash and lodash/fp; it returns a "new"ish Object without mutation.So the writer's example doesn't work
Why you gotta be a troll, man? Guy is just trying to show how cool Lodash is.
Not trolling. His examples don't show how good Lodash is, and - as we've established - the fourth example doesn't work if what you said about
setnot mutating is correctAll those "modern JS" native methods did not exist when Lodash was first conceptualized....
You are not wrong! Lodash has a bunch of methods that just make doing certain tasks easier. Adding Lodash to your Javascript project adds these methods some other frameworks like Django or Ruby on Rails would have out of the box. Such as the zip method in Ruby on Rails which will zip together two arrays into one. Javascript doesn't have this functionality out of the box... Lodash has a _.zip method. Don't get me wrong you could also do this with the array .map method in Javascript. As for the library overhead you could always import each method individually.
Ex. const zip = require("lodash/zip");
You certainly should only import the modules you use, otherwise a few convenience methods are taking up more space than whole frameworks like React. Functions such as
debounce()in lodash have tons of options that make them much heavier than lightweight implementations (which are mostly what it is used for) - if you aren't using the options for trailing and leading edges, it's costing "something".For me in big apps that are likely to use lots of utility methods over time, I'd take Sugar.js because that has some really useful functions - like Date.create("Next monday at 2pm"), debounce etc. It's also 1/3 the size of lodash if you include it all (and you don't have to).
Probably would have been better to show examples of where using Lodash would actually have some benefit
Maybe in my next post! 😉 say tuned lol!
'Tuned'
I see what you did there 👀
I don't know anything about ruby on rails but isn't that concat? w3schools.com/jsref/jsref_concat_a...
It's a little different concat would join the two arrays. So if you had [1, 3, 5] and [2, 4]. The results of concatenation would be [1, 3, 5, 2, 4]. The zip method would zip the two arrays together like a zipper. The results would look like this [1, 2, 3, 4, 5]
So basically concat + sort?
I think you have a point especially on the client - downloading dozens of extra KB's is not a good idea unless it's really necessary ... server side (node.js) this is less of an issue.
Recommendation: Do not use Lodash in current year.
Like others here have pointed out, It is a literal waste of kb's in your payload. :)
well,
import { debounce } from 'lodash';kinda takes your argument away (there are even separate packages for everything). also, in past years I'd been writing my own debounce function in every project, it isn't that a complex mechanism. I'm not that foolish any more. the lodash's version is superior and documented. and that's gist of it.debouncing is not Lodash tho, it’s part of the library by practical coincidence.
It could also be a separate package like you point out.
Lodash was made in an age when array methods where lacking and polyfiling was less common.
If they changed the focus of the library, then I did not get the memo. :)
in Lodash, I use debounce and cloneDeep most :)