
Why-did-you-update – Warnings about unnecessary React updates - ggurgone
https://github.com/garbles/why-did-you-update
======
acemarke
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/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/devtools.md#component-update-monitoring) .

[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...](https://github.com/markerikson/react-redux-
links/blob/master/react-performance.md)

[3] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

------
nathancahill
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.

~~~
uranian
> 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
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...](https://www.reddit.com/r/reactjs/comments/666uin/can_someone_explain_to_me_what_are_the_advantages/)
).

~~~
grovesNL
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.p...](https://facebook.github.io/react/docs/react-
api.html#react.purecomponent)

~~~
acemarke
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".

------
fzaninotto
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-
optim...](https://medium.com/dailyjs/react-is-slow-react-is-fast-optimizing-
react-apps-in-practice-394176a11fba)

~~~
foota
Won't functional components update on any change to props?

------
metalliqaz
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?

~~~
Etheryte
Here's how React works, in very broad strokes:

You have some data (props and state) that defines the current state of your
program. This data is passed to a rendering function, which creates a virtual
DOM representation of the component based on the data. After this has
happened, the virtual DOM is diffed against the previously built virtual DOM
to see if we should tell the browser to render the real DOM based on the new
virtual one.

So the general cycle works like this:

Data was updated -> virtual render -> diff new virtual DOM vs old virtual DOM
-> real render if necessary.

However, both constructing the virtual DOM as well as diffing the DOMs takes
considerable amounts of time. That's why React offers a short-cut to avoid it,
if necessary: shouldComponentUpdate. This lifecycle method is called after
your data updates and before the virtual render takes place, allowing you to
short-circuit the process if you already know that your data didn't change in
a way that changes the resulting DOM.

So with the short-circuit, there are two general pathways. If you know the
data didn't affect the DOM:

Data was updated -> return false in shouldComponentUpdate -> nothing more
happens.

If you know the data affects the DOM or you're not sure:

Data was updated -> return true in shouldComponentUpdate -> virtual render ->
diff new virtual DOM vs old virtual DOM -> real render if necessary.

The value of the tool is that it monkey-patches some React internals to notify
you when you have missed a chance to use shouldComponentUpdate properly.

~~~
acemarke
Good explanation, with one nitpick: the diff is done between the _old_ virtual
DOM tree and the _new_ virtual DOM tree, not between the virtual DOM tree and
the real DOM. That's why you can have a component that renders a single div,
and then get the reference to the real DOM node and use jQuery or some other
DOM-manipulating library to attach non-React-based DOM elements to the div. As
far as React knows, you're just telling it to keep rendering that same div, so
nothing needs to change.

~~~
Etheryte
Thanks for pointing that out, I've updated my comment to fix the mistake.

------
saifelse
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
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.

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

~~~
rhizome
It's probably a better indicator of their audience, the in-group. I don't know
how old you are, but this is what it's like to become a square.

The thing is, if you don't like it and get stuck on lingo, there's a good
chance you're going to be left behind by the future. Your complaint is a
symptom of falling into the out-group of the cutting edge, into becoming part
of The Previous Generation.

~~~
aaroninsf
Disagree.

Professionals push back towards professionalism, which should be free from
micro-culture in jokes. The profession is international, and there are many
indulging in this who do not have the perspective to recognize the actual cost
of insularity.

More to the point bro-grammer crap is explicitly barrier-raising. Clique-based
behavior, however graced with knowing winks, led directly to the current
crisis of culture in the Valley in general, and start-up culture in
particular.

As such it is most definitely at best in the category of funny-once.

And the joke played out long ago.

~~~
Karunamon
Says who? Who determines what professionalism means?

Because I have a definition that states you use the best tool for the job at
hand, rather than choosing (yes, _choosing_ ) to complain loudly about poorly-
described-and-argued ancillary matters which don't directly impact the
operation of said tool.

I reject the idea that "professionalism" means that the cheeky, mischevious
humor that has basically defined the hacker spirit for decades must be stamped
out or suppressed.

~~~
jakelazaroff
So where do we draw the line when that "cheeky, mischievous humor" actually
excludes people from our community?

Words _matter_. There are plenty of studies that show e.g. certain language in
job listings discourages women from applying: [https://qz.com/797559/gender-
bias-job-listings-language/](https://qz.com/797559/gender-bias-job-listings-
language/)

~~~
Karunamon
_So where do we draw the line when that "cheeky, mischievous humor" actually
excludes people from our community?_

When it can be reasonably proven that this is _actually happening_ in _this
case_. A reasonable start would be finding a real (as opposed to straw) person
who feels "excluded".

If "bruh" is legitimately "excluding people from the community" _in this
context_ (And let's be honest here: a job posting is not equivalent in any way
to a readme on a git repo), then by all means, let's have the conversation.

If it isn't? This is all just noise. Worse, actively harmful and distracting
noise.

------
golergka
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.

~~~
seattle_spring
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
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.

~~~
beart
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.

