10 ms·

Why-did-you-update – Warnings about unnecessary React updates

163 points by ggurgone 10y ago

acemarke 10y ago
This is a pretty useful utility. I have a number of other similar "why did this component re-render" tools listed in the "DevTools" section [0] of my Redux addons list [1]. I also have a large section of articles on React (and Redux) performance [2] in my React/Redux links list [3], which includes articles on measuring perf using various tools, optimizing re-renders, and more. [0] https://github.com/markerikson/redux-ecosystem-links/blob/master/devtools.md#component-update-monitoring https://github.com/markerikson/redux-ecosystem-links/blob/ma... . [1] https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links [2] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md https://github.com/markerikson/react-redux-links/blob/master... [3] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links
nathancahill 10y ago
Alternatively: Make all data immutable, then make all components pure. Finally, look for and fix breaking components, since those will point to code smells and anti-patterns (using context incorrectly, mutating data, non-unidirectional data flow). Not only do you get a big performance boost, but your code is greatly improved.
- ggurgone 10y ago
  Agreed! In the meantime I think that this lib is very nice. Fine tuning performance is an art and requires knowledge and time.
- uranian 10y ago
  > 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 10y 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 10y 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 10y 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 10y 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.
- Kiro 10y ago
  Do you have any code examples using this pattern?
  - nathancahill 10y ago
    Yeah, I might publish a blog post soon. Sign up to my mailing list here: http://nathancahill.com/ http://nathancahill.com/
shaggyfrog 10y ago
Words like "bruh" and "gainz" send a signal that is probably better off un-sent.
- reilly3000 10y ago
  Chill brah
- ocharles 10y ago
  That's right, we should always strive to assess technical projects based on how the author communicates.
  - cbhl 10y ago
    I realize you're being sarcastic, but certain forms of communication anecdotally correlate with inappropriate behavior (harassment, offensive verbal remarks, stalking, gender discrimination). Even if the tone is being used facetiously -- especially when it is being used facetiously -- we must be clear in communicating what behavior is and isn't acceptable. Failing to do so makes women feel uncomfortable, and teaches impressionable young coders (the college kids that typically have time to write sarcastic open-source one-off projects) that this kind of thing is okay.
    - praneshp 10y ago
      > Failing to do so makes women feel uncomfortable Honest question, are you a woman? I generally agree that our industry has to do a lot more work to make everyone feel included and utilize all the talent available. But I disagree that using the word 'bruh' should be discouraged, or that it correlates with inappropriate behavior. Especially if it's anecdotal, its just correlation, not causation, and shouldn't be read into. (Unless 'bruh' has a meaning other than 'bro', short for 'brother', that I don't know about).
      - jayqui 10y ago
        Shouldn't we err on the side of not excluding or offending people if there's a reasonable possibility that we would be?
golergka 10y ago
Oh. I thought it would question your unneccessary update of dependencies that didn't close any bugs or introduce new features but require you 3 days to change code according to a new API.
- ggurgone 10y ago
  ha! Indeed I thought the same at first but then got excited anyway when I understood what it does.
- dickbasedregex 10y ago
  So like node.js in a nutshell?
- seattle_spring 10y ago
  If it took you 3 days to update React then you should definitely look at jscodeshift. It should have taken you a few hours at most regardless of the size of your codebase.
  - golergka 10y ago
    Everything I know about React I know from HN. Guilty, criticizing tech I've never used - but it's more about the whole constant update mentality than React in particular.
    - deleted 10y ago
      [deleted]
    - beart 10y ago
      I worked with Node all the time and have not really found this to be a problem unless the package maintainer fails to publish a change log or fails to follow semvar correctly.
artana 10y ago
http://www.webmhs.com/2017/04/prediksi-manchester-united-vs-Anderlecht.html http://www.webmhs.com/2017/04/prediksi-manchester-united-vs-...
metalliqaz 10y ago
Not a front-end dev here, but I thought the whole point of a virtual DOM was to allow you to refresh the whole interface all the time and allow the library to only render the differences. Wouldn't this tool negate that purpose?
- coltonv 10y ago
  So recalculating the virtual DOM is fast, but it does have a cost. The easy way to combat this cost is to realize that if you're doing things right and using pure functions, you'll get the exact same UI if you're state hasn't changed. So if you know the state that feeds into a certain component hasn't changed, you can get much better performance. This library basically encourages you to use React's "PureComponent", which automatically does that calculation to see if the props have changed for you, thus giving you a huge speedup since only the components that need to update will.
  - Kiro 10y ago
    Why isn't PureComponent just default?
    - acemarke 10y ago
      A few reasons: - PureComponent was only added relatively recently. - While shallow equality comparisons are relatively fast compared to deep equality comparisons, they still burn CPU. There's also a number of reasons why props could have changed, such as object literals being declared in the parent's `render` method, or the component receiving other components via `props.children`. In those cases, the "pure" comparison will fail every time, and be useless. - There is no "default" per se. Application components explicitly extend a React component base class - either React.Component, or React.PureComponent.
    - vinnymac 10y ago
      It is not a bullet proof solution. It has its use cases, but a couple pitfalls as well. Using PureComponent as a parent to many Component classes is generally not a good idea. If a child depends on a change from `this.context` it will not re-render unless the PureComponent declares `contextTypes`. https://github.com/facebook/react/issues/2517 https://github.com/facebook/react/issues/2517
saifelse 10y ago
Author of the Benchling mixin / blog post, here. Thanks for including the credit and for making this technique more easily usable! I'm quite happy that this is being utilized by so many people :-)
davidy123 10y ago
Another kit along these lines is https://github.com/leoasis/redux-immutable-state-invariant https://github.com/leoasis/redux-immutable-state-invariant While in development mode it warns of changes to the Redux state, without having to commit to something like Immutable.js.
fzaninotto 10y ago
Unfortunately, this package hasn't been updated for a long time, which makes is almost useless today. For instance, it doesn't know how to track functional components - that's really a pity. For alternative re-rendering troubleshooting, read https://medium.com/dailyjs/react-is-slow-react-is-fast-optimizing-react-apps-in-practice-394176a11fba https://medium.com/dailyjs/react-is-slow-react-is-fast-optim...
- foota 10y ago
  Won't functional components update on any change to props?

163 points by ggurgone 10y ago

This is a pretty useful utility. I have a number of other similar "why did this component re-render" tools listed in the "DevTools" section [0] of my Redux addons list [1]. I also have a large section of articles on React (and Redux) performance [2] in my React/Redux links list [3], which includes articles on measuring perf using various tools, optimizing re-renders, and more. [0] https://github.com/markerikson/redux-ecosystem-links/blob/master/devtools.md#component-update-monitoring https://github.com/markerikson/redux-ecosystem-links/blob/ma... . [1] https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links [2] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md https://github.com/markerikson/react-redux-links/blob/master... [3] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links

nathancahill 10y ago

Alternatively: Make all data immutable, then make all components pure. Finally, look for and fix breaking components, since those will point to code smells and anti-patterns (using context incorrectly, mutating data, non-unidirectional data flow). Not only do you get a big performance boost, but your code is greatly improved.

ggurgone 10y ago
Agreed! In the meantime I think that this lib is very nice. Fine tuning performance is an art and requires knowledge and time.
uranian 10y ago
> 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 10y 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 10y 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 10y 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 10y 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.
Kiro 10y ago
Do you have any code examples using this pattern?
- nathancahill 10y ago
  Yeah, I might publish a blog post soon. Sign up to my mailing list here: http://nathancahill.com/ http://nathancahill.com/

shaggyfrog 10y ago

Words like "bruh" and "gainz" send a signal that is probably better off un-sent.

reilly3000 10y ago
Chill brah
ocharles 10y ago
That's right, we should always strive to assess technical projects based on how the author communicates.
- cbhl 10y ago
  I realize you're being sarcastic, but certain forms of communication anecdotally correlate with inappropriate behavior (harassment, offensive verbal remarks, stalking, gender discrimination). Even if the tone is being used facetiously -- especially when it is being used facetiously -- we must be clear in communicating what behavior is and isn't acceptable. Failing to do so makes women feel uncomfortable, and teaches impressionable young coders (the college kids that typically have time to write sarcastic open-source one-off projects) that this kind of thing is okay.
  - praneshp 10y ago
    > Failing to do so makes women feel uncomfortable Honest question, are you a woman? I generally agree that our industry has to do a lot more work to make everyone feel included and utilize all the talent available. But I disagree that using the word 'bruh' should be discouraged, or that it correlates with inappropriate behavior. Especially if it's anecdotal, its just correlation, not causation, and shouldn't be read into. (Unless 'bruh' has a meaning other than 'bro', short for 'brother', that I don't know about).
    - jayqui 10y ago
      Shouldn't we err on the side of not excluding or offending people if there's a reasonable possibility that we would be?

golergka 10y ago

Oh. I thought it would question your unneccessary update of dependencies that didn't close any bugs or introduce new features but require you 3 days to change code according to a new API.

ggurgone 10y ago
ha! Indeed I thought the same at first but then got excited anyway when I understood what it does.
dickbasedregex 10y ago
So like node.js in a nutshell?
seattle_spring 10y ago
If it took you 3 days to update React then you should definitely look at jscodeshift. It should have taken you a few hours at most regardless of the size of your codebase.
- golergka 10y ago
  Everything I know about React I know from HN. Guilty, criticizing tech I've never used - but it's more about the whole constant update mentality than React in particular.
  - deleted 10y ago
    [deleted]
  - beart 10y ago
    I worked with Node all the time and have not really found this to be a problem unless the package maintainer fails to publish a change log or fails to follow semvar correctly.

artana 10y ago

http://www.webmhs.com/2017/04/prediksi-manchester-united-vs-Anderlecht.html http://www.webmhs.com/2017/04/prediksi-manchester-united-vs-...

metalliqaz 10y ago

Not a front-end dev here, but I thought the whole point of a virtual DOM was to allow you to refresh the whole interface all the time and allow the library to only render the differences. Wouldn't this tool negate that purpose?

coltonv 10y ago
So recalculating the virtual DOM is fast, but it does have a cost. The easy way to combat this cost is to realize that if you're doing things right and using pure functions, you'll get the exact same UI if you're state hasn't changed. So if you know the state that feeds into a certain component hasn't changed, you can get much better performance. This library basically encourages you to use React's "PureComponent", which automatically does that calculation to see if the props have changed for you, thus giving you a huge speedup since only the components that need to update will.
- Kiro 10y ago
  Why isn't PureComponent just default?
  - acemarke 10y ago
    A few reasons: - PureComponent was only added relatively recently. - While shallow equality comparisons are relatively fast compared to deep equality comparisons, they still burn CPU. There's also a number of reasons why props could have changed, such as object literals being declared in the parent's `render` method, or the component receiving other components via `props.children`. In those cases, the "pure" comparison will fail every time, and be useless. - There is no "default" per se. Application components explicitly extend a React component base class - either React.Component, or React.PureComponent.
  - vinnymac 10y ago
    It is not a bullet proof solution. It has its use cases, but a couple pitfalls as well. Using PureComponent as a parent to many Component classes is generally not a good idea. If a child depends on a change from `this.context` it will not re-render unless the PureComponent declares `contextTypes`. https://github.com/facebook/react/issues/2517 https://github.com/facebook/react/issues/2517

saifelse 10y ago

Author of the Benchling mixin / blog post, here. Thanks for including the credit and for making this technique more easily usable! I'm quite happy that this is being utilized by so many people :-)

davidy123 10y ago

Another kit along these lines is https://github.com/leoasis/redux-immutable-state-invariant https://github.com/leoasis/redux-immutable-state-invariant While in development mode it warns of changes to the Redux state, without having to commit to something like Immutable.js.

fzaninotto 10y ago

Unfortunately, this package hasn't been updated for a long time, which makes is almost useless today. For instance, it doesn't know how to track functional components - that's really a pity. For alternative re-rendering troubleshooting, read https://medium.com/dailyjs/react-is-slow-react-is-fast-optimizing-react-apps-in-practice-394176a11fba https://medium.com/dailyjs/react-is-slow-react-is-fast-optim...

foota 10y ago
Won't functional components update on any change to props?