Re:Lodash's Chain vs. Native Methods
by brundolf on Thursday August 26, 2021 @09:47PM
(#28323416)
It's a slightly contrived example, but it demonstrates a real situation that can come up. Suppose instead it was:
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 filter(), instead of keeping those concerns separate and re-using values:
You could of course share the business logic by abstracting it into a function:
But you'd still be doing the work twice. In this example it's trivial, but in a real-world scenario it might not be.
[ Parent
| on HN ]
Re:Lodash's Chain vs. Native Methods
by darepublic on Friday August 27, 2021 @09:55AM
(#28327837)
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
by darepublic on Saturday August 28, 2021 @11:04AM
(#28338607)
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.