3 ms·

I've been using this library for over a year, I'd say if you have an existing project that you'd like to use Immutable objects in then it's a great choice with

I've been using this library for over a year, I'd say if you have an existing project that you'd like to use Immutable objects in then it's a great choice with minimal downsides. For a greenfield project Immutable.js is probably a better bet as the newer data structures come with a lot of benefits.

kasbah 9y ago
I have just started a React-Redux project using Immutable.js and am considering switching it over to this as I can see a lot of advantages in the compatibility with JS data. What downsides do you think I would encounter after switching?
- tommoor 9y ago
  The main thing I can think of is that it will add all it's internal methods to your objects, which restricts which properties you can use – eg, "update", "merge" etc. This isn't usually an issue but we happened to have some policy objects with the same property names. It also doesn't play nicely with Flow unless you use the static syntax.
  - kasbah 9y ago
    Ah, wasn't aware. Good to know. Well, I never did get Immutable.js to play nicely with Flow which is kind of why I gave up on Flow. I wondered if you might have something to say on performance issues. You didn't encounter anything of that sort?
    - tommoor 9y ago
      Performance was the main reason we switched over. We found using Immutable objects to be the key to a performant UI when using something like React that's diffing your props every render loop.
      - kasbah 9y ago
        So you would have your props be Immutable.js objects? I wasn't sure if doing that would be a good idea but sounds like that has worked out for you.
- acemarke 9y ago
  I wrote a long Reddit comment a while back that describes the reasons why I advise that people _not_ use Immutable.js [0]. As a quick summary: - It doesn't magically improve perf the way some people think it will. It does make easier to use the standard shallow equality implementation of `shouldComponentUpdate`, and can be faster at copying/updating very large objects. However, many people use `toJS()` to extract values, and that is absolutely bad for perf (especially if you call it in `mapState`). - You either have to use its API everywhere in your codebase, or spend a lot of time encapsulating it to keep your components unaware of its existence. - It can be harder to debug the contents of the objects. I'm not sure about specific downsides for using Seamless-Immutable. My React/Redux links list has a section of articles that discuss the pros and cons of using Immutable.js for performance [1]. I've also got a section on use of immutable data in general [2], including some articles that talk about how to actually use Immutable.js in your app, and articles on using plain JS data immutably. [0] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4/?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md https://github.com/markerikson/react-redux-links/blob/master...
  - kasbah 9y ago
    You don't appear to be actually responding to my question but are giving unsolicited advice and plugging your projects :/
    - acemarke 9y ago
      I actually misread your question a bit at first - I originally thought you were asking about switching _to_ Immutable.js, not away from it. I realized that before I posted it, and decided my answer was still relevant to the aspect of "why someone might want to switch away from Immutable.js". So, in that sense it's adding context to the reasoning behind your question. As I said, I'm not aware of specific downsides to using Seamless-Immutable. It seems like a good balance of enforced immutability in development via freezing and replacement of mutation methods, and compatibility with standard JS object/array notation and usage.
- deleted 9y ago
  [deleted]
lewisl9029 9y ago
With something like ImmutableJS or Mori, or any other persistent data structure library that doesn't use native JS objects, there's just a lot of general friction during development that can seriously slow down both developer productivity (dealing with interop, losing access to object destructuring, spread, being limited to data access/mutation APIs provided by the libraries, difficulty in debugging, etc) and actual app performance (converting to or from JS is often expensive and can completely negate the perf benefits of the persistent data structures when overused in the wrong places, and it's extremely easy to overuse it in the wrong places if you're not familiar with React/Redux's inner workings). If you manage to avoid all performance pitfalls and can accept some degree of loss in dev productivity, then the performance benefits from structural sharing and laziness can still be worthwhile for a sufficiently data-heavy app. For most other cases it's a very costly premature optimization though. The Redux docs actually has a very thorough document on the pros and cons of using persistent data structure libraries with Redux: http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html I'm still hoping for native JS persistent data structures to make it into the ECMAScript spec at some point in the future. The only thing I've found so far is this: https://github.com/sebmarkbage/ecmascript-immutable-data-structures https://github.com/sebmarkbage/ecmascript-immutable-data-str... And I'm not sure if it has gained much traction. Until native JS persistent data structures get implemented and gain widespread support, I think something like seamless-immutable might be a reasonable compromise.

kasbah 9y ago

I have just started a React-Redux project using Immutable.js and am considering switching it over to this as I can see a lot of advantages in the compatibility with JS data. What downsides do you think I would encounter after switching?

tommoor 9y ago
The main thing I can think of is that it will add all it's internal methods to your objects, which restricts which properties you can use – eg, "update", "merge" etc. This isn't usually an issue but we happened to have some policy objects with the same property names. It also doesn't play nicely with Flow unless you use the static syntax.
- kasbah 9y ago
  Ah, wasn't aware. Good to know. Well, I never did get Immutable.js to play nicely with Flow which is kind of why I gave up on Flow. I wondered if you might have something to say on performance issues. You didn't encounter anything of that sort?
  - tommoor 9y ago
    Performance was the main reason we switched over. We found using Immutable objects to be the key to a performant UI when using something like React that's diffing your props every render loop.
    - kasbah 9y ago
      So you would have your props be Immutable.js objects? I wasn't sure if doing that would be a good idea but sounds like that has worked out for you.
acemarke 9y ago
I wrote a long Reddit comment a while back that describes the reasons why I advise that people _not_ use Immutable.js [0]. As a quick summary: - It doesn't magically improve perf the way some people think it will. It does make easier to use the standard shallow equality implementation of `shouldComponentUpdate`, and can be faster at copying/updating very large objects. However, many people use `toJS()` to extract values, and that is absolutely bad for perf (especially if you call it in `mapState`). - You either have to use its API everywhere in your codebase, or spend a lot of time encapsulating it to keep your components unaware of its existence. - It can be harder to debug the contents of the objects. I'm not sure about specific downsides for using Seamless-Immutable. My React/Redux links list has a section of articles that discuss the pros and cons of using Immutable.js for performance [1]. I've also got a section on use of immutable data in general [2], including some articles that talk about how to actually use Immutable.js in your app, and articles on using plain JS data immutably. [0] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4/?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md https://github.com/markerikson/react-redux-links/blob/master...
- kasbah 9y ago
  You don't appear to be actually responding to my question but are giving unsolicited advice and plugging your projects :/
  - acemarke 9y ago
    I actually misread your question a bit at first - I originally thought you were asking about switching _to_ Immutable.js, not away from it. I realized that before I posted it, and decided my answer was still relevant to the aspect of "why someone might want to switch away from Immutable.js". So, in that sense it's adding context to the reasoning behind your question. As I said, I'm not aware of specific downsides to using Seamless-Immutable. It seems like a good balance of enforced immutability in development via freezing and replacement of mutation methods, and compatibility with standard JS object/array notation and usage.
deleted 9y ago
[deleted]

lewisl9029 9y ago

With something like ImmutableJS or Mori, or any other persistent data structure library that doesn't use native JS objects, there's just a lot of general friction during development that can seriously slow down both developer productivity (dealing with interop, losing access to object destructuring, spread, being limited to data access/mutation APIs provided by the libraries, difficulty in debugging, etc) and actual app performance (converting to or from JS is often expensive and can completely negate the perf benefits of the persistent data structures when overused in the wrong places, and it's extremely easy to overuse it in the wrong places if you're not familiar with React/Redux's inner workings). If you manage to avoid all performance pitfalls and can accept some degree of loss in dev productivity, then the performance benefits from structural sharing and laziness can still be worthwhile for a sufficiently data-heavy app. For most other cases it's a very costly premature optimization though. The Redux docs actually has a very thorough document on the pros and cons of using persistent data structure libraries with Redux: http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html I'm still hoping for native JS persistent data structures to make it into the ECMAScript spec at some point in the future. The only thing I've found so far is this: https://github.com/sebmarkbage/ecmascript-immutable-data-structures https://github.com/sebmarkbage/ecmascript-immutable-data-str... And I'm not sure if it has gained much traction. Until native JS persistent data structures get implemented and gain widespread support, I think something like seamless-immutable might be a reasonable compromise.