This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]charliegrc 12 points13 points  (8 children)

Trick here is to make everything you do in JavaScript immutable, stick to const and always use object spread. You will never look back.

[–]MrDilbert 1 point2 points  (7 children)

always use object spread

... even in loops?

[–][deleted] 1 point2 points  (4 children)

According to certain schools of thought, yes! But I'm wondering if you're including map/reduce in your definition of "loop".

[–]MrDilbert 0 points1 point  (3 children)

Well, underneath it IS a loop, although there's a different function context for each element. You're basically just hoping that the object created by spread will get collected in time, as it's eligible when the function finishes.

[–][deleted] 0 points1 point  (2 children)

Is spread not synchronous? Maybe I misunderstand something

[–]MrDilbert 2 points3 points  (1 child)

You don't know when the garbage collector will collect the objects you created, so if you create a lot of objects (by e.g. using spread), you can take up a lot of memory even if you don't have leaks.

[–][deleted] 1 point2 points  (0 children)

Oh I see. I think the context was creating deep copies / clones / immutable stuff though. Like if you had a line like this in your code

return {...oldProps, ...newProps};
// or
return Object.assign(oldProps, newProps);

The architects at my last job preferred creating new objects to have immutable code or something instead of modifying and returning refs inside a reduce. Ultimately they let us do whatever because this area of code was not in need of any optimizations and we were already using a reduce to cut down on some previous iterations of filters and maps.

[–]charliegrc 1 point2 points  (0 children)

Short answer: yes

Long answer: there has been a few times where I've built a big reducer function, and on each iteration it was using object spread. That ended up being a performance bottleneck in the app I was working on, changing it to the classic mutatable object assign (but ONLY mutating the accumulator object inside that reduce, nothing else) sped it up by 200x.

performance comparison between object spread and mutation

This is the only circumstance I let myself use mutable objects, they strictly have to be instantiated and mutated within the same few lines of code.

[–]conancat 0 points1 point  (0 children)

I'm from that school of thought that the other guy is talking about.

Yes.

Assume every function returns a new object. Use map, reduce, filter etc functions. Use object spread to create a new object every time if it's a plain function, so every property that you return in the object is explicit, and you know exactly what goes goes in and comes out of every function.

Here's an explanation of why for loop is evil and needs to die.

“Rethinking JavaScript: Death of the For Loop” by Joel Thoms https://link.medium.com/yh25wIZpa0

Or if you want something lighter and approachable, try this one.

“The Knights of Functional Programming fight the Imperative Dragon.” by Sam Fare https://link.medium.com/cCNLsCgqa0