Live data from Hacker News

Lodash's Chain vs. Native Methods

maartenhus.nl

21–25 of 25 posts

Re: Lodash's Chain vs. Native Methods

#21
post #14

In the article when comparing the native vs lodash implementation the native one is given as: persons .map(p => ({ ...p, age: p.age + 1 })) .filter(p => p.age >= 30) .slice(0, 5); ^ But this is intentionally(?) unoptimized. You would instead put the filter and slice first, i.e. person.filter(p => p.age >= 29) .slice(0,5) .map(p => ({...p, age: p.age + 1})

Yes, but this will still filter through all the items, instead of stopping at 5.

I don't see how lodash could possibly filter a list of 30 by a criteria without visiting each item at least once to take a look at it. the only way to make it more efficient would be to have lodash collect the desired transformations (filter/map) and then run a single loop over the items, mapping only those items that meet the filter criteria. But that is not much more efficient than the [].filter().map() that you could do with native methods.

Re: Lodash's Chain vs. Native Methods

#22

Earlier quoted context omitted.

It's a slightly contrived example, but it demonstrates a real situation that can come up. Suppose instead it was: const drinkingAge = 21 persons .map(p => ({ ...p, canDrink: p.age >= drinkingAge })) .filter(p => p.canDrink) .slice(0, 5); Assuming we want `canDrink` to exist in those objects for later use, reversing the steps here would mean duplicating the logic and the work of computing it across the map() and the f…

if you are using slice(0,5) then all the extra objects you mapped are lost and you have no reference to them.

Not true. slice() clones-and-drops the array, but not the objects inside.

Re: Lodash's Chain vs. Native Methods

#23
post #14

Earlier quoted context omitted.

Yes, but this will still filter through all the items, instead of stopping at 5.

I don't see how lodash could possibly filter a list of 30 by a criteria without visiting each item at least once to take a look at it. the only way to make it more efficient would be to have lodash collect the desired transformations (filter/map) and then run a single loop over the items, mapping only those items that meet the filter criteria. But that is not much more efficient than the [].filter().map() that you co…

It doesn't have to visit all 30 items, just enough items to take 5 from, could be 8, could be 10 etc. The lazy approach _is_ to collect all transformations and apply them in the end.

Re: Lodash's Chain vs. Native Methods

#24
post #23

Earlier quoted context omitted.

I don't see how lodash could possibly filter a list of 30 by a criteria without visiting each item at least once to take a look at it. the only way to make it more efficient would be to have lodash collect the desired transformations (filter/map) and then run a single loop over the items, mapping only those items that meet the filter criteria. But that is not much more efficient than the [].filter().map() that you co…

It doesn't have to visit all 30 items, just enough items to take 5 from, could be 8, could be 10 etc. The lazy approach _is_ to collect all transformations and apply them in the end.

ah, yeah you are right.

Re: Lodash's Chain vs. Native Methods

#25

Earlier quoted context omitted.

if you are using slice(0,5) then all the extra objects you mapped are lost and you have no reference to them.

Not true. slice() clones-and-drops the array , but not the objects inside.

but map also creates a new array, and within map you are not mutating the items of the old array but creating brand new ones no? [...].map(p => ({...p, canDrink}))

^ the original items of the array are not mutated in this map callback. you could mutate them if you really wanted, i.e.

[...].map(p => {p.canDrink = p.age > 20; return p})

but that is a straight up hack.

Post reply on HN