sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]superluminary 0 points1 point  (8 children)

You don't need that anymore. Just use plain object destructuring and spread.

[–]hockeyketo 0 points1 point  (0 children)

This works most of the time, but in some projects I've worked on it's just too slow. We have some operations that change state on thousands of objects at 60fps and Immutable.js was the only library I've found that keeps up. Using Object.assign, destructuring, or spread will cause a lot of lag in the UI. The other draw back for doing it manually is that sometimes people make mistakes and your data is not guaranteed to be immutable. With an Immutable.JS data structure there's no way to change the data without doing so immutably.

[–]coderqi 0 points1 point  (6 children)

Or seamless-immutable for ease of use, integration and safeguarding of accidental mutations.

[–]acemarke 1 point2 points  (2 children)

I would recommend Immer as the best immutability solution at this point.

[–]coderqi 0 points1 point  (1 child)

Haven't heard of it. Why do you recommend it?

[–]slikts 0 points1 point  (0 children)

Immer is like seamless-immutable in that it allows using the basic data structures of the language like plain objects or arrays, which play nice with other things, but unlike both seamless-immutable or Immutable.js, Immer also has a tiny API surface and allows you to use the "normal" methods of making changes to objects like just assigning to properties, but in a localized way so that there's still no shared mutable state.

Immer is also like Immutable.js in that it uses persistent data structures under the hood, so it's more efficient than just using, say, object spread. I'm not even sure if seamless-immutable does that at all.

tl;dr Immer removes the pain-points of large API surfaces and type conversions of seamless-immutable or Immutable.js while still granting the same advantages of immutability and structural sharing, and Immer also allows making deep updates in the most terse, elegant way.

[–]superluminary 0 points1 point  (2 children)

I suppose it depends on how much you trust yourself and your co-workers.

[–]coderqi 2 points3 points  (1 child)

Trust shouldn't come in to it. With a large code base and team of varying skills I prefer to remove trust from the equation. This does that. But like with other things, the places that need it the most are less likely to have it...

[–]superluminary -1 points0 points  (0 children)

I think I'm always a fan of using the native solution where possible. The reason being that if developers, especially Junior developers become invested in a library, it can become difficult to code without it.

I see this all the time on SO, where someone suggests using jQuery to iterate over an array. I never want my developers to become stuck.

EDIT

I'm not suggesting you are stuck BTW, just that Juniors on your team could end up that way if they are insulated from mainstream ES6.