Discussion on: 5 Must Know Lodash Methods

[Jon Randy 🎖️]

1.

const myFavCandy = foodObj ?. favFoods[3] ?. favCandy || 'Chocolate'

2.

const myNewBestFriend = adoptableDogs.find(dog => dog.breed=="White Lab" && dog.age>2)

3.

const adoptableDogsNames = adoptableDogs.map(dog => dog.name)

4.

adoptableDogs[2].age = 1

No 72.5Kb of lodash even remotely required

[Sergio Martín]

All those "modern JS" native methods did not exist when Lodash was first conceptualized....

[Jesse Warden]

Some points:

1. 4 is doing mutation. In Lodash, set safely gives you a new object (not deep clone, but property copy)
2. 1 - 4 cannot be curried in normal JavaScript unless you manually wrap them. When you start composing functions, whether using Promise, your own composition, or the new pipeline operator, you end up wrapping all this stuff.

const map_ = func => array => array.map(func)
const find_ = func => array => array.find(func)
["1", "2", "3"]
|> map_(parseInt)
|> find_(isEven)

1. You can re-use the partially applied functions in 2; creating these yourself just to re-use is tiresome.
2. Not all JavaScript supports this. Many of us still deal with various IE or old Node.js versions that can't be upgraded yet. #inb4Babel This is why we use Lodash, not just 5 methods that happen to have equivalent features in "the latest JS". We agree with you that if you have that ability in the browser or your current version of Node.js, yes yes, totally use the native functionality.
3. Outside of AWS Lambda, filesize doesn't matter in Node.js.

[Jon Randy 🎖️]

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

[Jesse Warden]

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.

[Jon Randy 🎖️]

Ah ok, your comments were referencing a functional version of Lodash

[Jesse Warden]

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.

[Jon Randy 🎖️]

So the writer's example doesn't work

[Jesse Warden]

Why you gotta be a troll, man? Guy is just trying to show how cool Lodash is.

[Jon Randy 🎖️]

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 set not mutating is correct

[Petros Vasileiou]

In 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.

[Jon Randy 🎖️]

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