4 ms·

> Not only do you get a big performance boost, Depends on the size of your data. AFAIK handling immutable data has a performance penalty on smaller datasets. B

> Not only do you get a big performance boost, Depends on the size of your data. AFAIK handling immutable data has a performance penalty on smaller datasets. Before I go immutable I first assess whether I really need it.

acemarke 9y ago
It's important to note that there's a difference between "handling data immutably" and "using the Immutable.js library". It's completely possible to handle plain JS data immutably _without_ using Immutable.js. There's a few different reasons why handling data immutably in a React app is a good thing. The main one is that it allows straightforward implementation of `shouldComponentUpdate` by simply doing shallow equality checks against props and state to see if anything has changed. (I wrote a Reddit comment yesterday explaining why that works well, at https://www.reddit.com/r/reactjs/comments/666uin/can_someone_explain_to_me_what_are_the_advantages/ https://www.reddit.com/r/reactjs/comments/666uin/can_someone... ).
- grovesNL 9y ago
  You don't need to write shallow equality checks on each component if you're treating props/state as immutable. You can use React's PureComponent which automatically does this for you: https://facebook.github.io/react/docs/react-api.html#react.purecomponent https://facebook.github.io/react/docs/react-api.html#react.p...
  - acemarke 9y ago
    Which does the exact kind of shallow equality checks I was just describing :) The point is that for shallow equality checks to work properly, you do have to handle data immutably - such as using `someArray.concat(item)` instead of `someArray.push(item)`, because otherwise passing in the same references is interpreted as "nothing as changed".
- lobster_johnson 9y ago
  Shallow equality is not a panacea -- it doesn't avoid updates when the content is the same, something which can easily happen. For example, say you have an action that fetches a bunch of blog posts, then refetches later. If all the items are identical since the last fetch, you want to avoid rendering. So that means that whenever you deal with data updates, de-duplication has to occur at some point, preferably early on in the data layer when the surface area is minimal. That de-duplication would need to "intern" data; i.e. if you fetch the new blog posts, check each of them if they are exactly the same as what's already cached (time stamps or version numbers could be used to save deep equality checks), and keep the existing object if that's the case. Of course, you will still end up with lots of identical objects (different identity, but same content) purely because mutations generate them. For example, a user goes to a text field, types a character and then hits backspace. Now you've produced three different objects: version 0 (original data), version 1 (character added), version 2 (identical to v0, different identity). This will correctly re-render each version, of course. But let's say you had some other component (like a preview) that only updated every second. It would receive v0, v1, v2; at this point the delta of v2-v0 is zero, and there's no need to re-render; but a shallow equality check would cause it to. So de-duping needs to be built into all sorts of places you might not anticipate.
- wildpeaks 9y ago
  Deeply frozen data is a good middle ground to have immutability without Immutable.js: during development, automated tests can catch code that would attempt to mutate, and you have the option to remove the deep freezing in the release version to have no runtime penalty once you're confident that nothing can mutate the data.
nathancahill 9y ago
As far as React goes, the performance increase with immutable/pure components more than offsets the penalty of using immutable structures and having to "copy"[0] data to change it. Of course, it depends on the app, if your data is change-heavy, this will be less true. [0] Vanilla JS immutable types heavily optimize this. Immutable.js does as well, although there's obviously more overhead.
- grandalf 9y ago
  What vinalla js immutable types?
  - nathancahill 9y ago
    Strings, integers, etc

acemarke 9y ago

It's important to note that there's a difference between "handling data immutably" and "using the Immutable.js library". It's completely possible to handle plain JS data immutably _without_ using Immutable.js. There's a few different reasons why handling data immutably in a React app is a good thing. The main one is that it allows straightforward implementation of `shouldComponentUpdate` by simply doing shallow equality checks against props and state to see if anything has changed. (I wrote a Reddit comment yesterday explaining why that works well, at https://www.reddit.com/r/reactjs/comments/666uin/can_someone_explain_to_me_what_are_the_advantages/ https://www.reddit.com/r/reactjs/comments/666uin/can_someone... ).

grovesNL 9y ago
You don't need to write shallow equality checks on each component if you're treating props/state as immutable. You can use React's PureComponent which automatically does this for you: https://facebook.github.io/react/docs/react-api.html#react.purecomponent https://facebook.github.io/react/docs/react-api.html#react.p...
- acemarke 9y ago
  Which does the exact kind of shallow equality checks I was just describing :) The point is that for shallow equality checks to work properly, you do have to handle data immutably - such as using `someArray.concat(item)` instead of `someArray.push(item)`, because otherwise passing in the same references is interpreted as "nothing as changed".
lobster_johnson 9y ago
Shallow equality is not a panacea -- it doesn't avoid updates when the content is the same, something which can easily happen. For example, say you have an action that fetches a bunch of blog posts, then refetches later. If all the items are identical since the last fetch, you want to avoid rendering. So that means that whenever you deal with data updates, de-duplication has to occur at some point, preferably early on in the data layer when the surface area is minimal. That de-duplication would need to "intern" data; i.e. if you fetch the new blog posts, check each of them if they are exactly the same as what's already cached (time stamps or version numbers could be used to save deep equality checks), and keep the existing object if that's the case. Of course, you will still end up with lots of identical objects (different identity, but same content) purely because mutations generate them. For example, a user goes to a text field, types a character and then hits backspace. Now you've produced three different objects: version 0 (original data), version 1 (character added), version 2 (identical to v0, different identity). This will correctly re-render each version, of course. But let's say you had some other component (like a preview) that only updated every second. It would receive v0, v1, v2; at this point the delta of v2-v0 is zero, and there's no need to re-render; but a shallow equality check would cause it to. So de-duping needs to be built into all sorts of places you might not anticipate.
wildpeaks 9y ago
Deeply frozen data is a good middle ground to have immutability without Immutable.js: during development, automated tests can catch code that would attempt to mutate, and you have the option to remove the deep freezing in the release version to have no runtime penalty once you're confident that nothing can mutate the data.

nathancahill 9y ago

As far as React goes, the performance increase with immutable/pure components more than offsets the penalty of using immutable structures and having to "copy"[0] data to change it. Of course, it depends on the app, if your data is change-heavy, this will be less true. [0] Vanilla JS immutable types heavily optimize this. Immutable.js does as well, although there's obviously more overhead.

grandalf 9y ago
What vinalla js immutable types?
- nathancahill 9y ago
  Strings, integers, etc