> Let's say that again. If anything, anywhere in your app has changed, throw the whole thing away and re-render the whole thing.
I am not an expert in React, but I am fairly certain this is completely false. React will re-render the components where state has changed, as well as any children of that components whose props change as a result. This is one of the key advantages of unidirectional data flow, as it makes it easy to reason about which components need to re-render as a result of a state change.
Maybe it depends on your definition of "re-render". When I say re-render, I mean getting React to run your render method, in which you're returning React elements.
By default, shouldComponentUpdate always returns true, so if a component re-renders, meaning you change state or props for that component, your render method is called again, and then all the child components (unless shouldComponentUpdate has been overridden) will also in turn have their render methods called. This will happen regardless of whether or not the props are the same. In fact, I often do this at the top, just calling setState with the same props (to a mutable object) to kick off another render.
This is all just JavaScript though and so is very fast. React is then mapping these elements to DOM nodes (which is slow). For that, it uses a very smart diffing algorithm to determine which DOM nodes need to be changed. (Maybe that's your definition of re-render.) So only the DOM elements that have actually changed get touched.
You can, if you want, use the PureRenderMixin to make React only re-render if the props or state actually change. The mixin just leverages shouldComponentUpdate to do this. This can be a bit of a can of worms though, so I kept this out of my beginnerish post.
2 comments
[ 3.4 ms ] story [ 12.4 ms ] threadI am not an expert in React, but I am fairly certain this is completely false. React will re-render the components where state has changed, as well as any children of that components whose props change as a result. This is one of the key advantages of unidirectional data flow, as it makes it easy to reason about which components need to re-render as a result of a state change.
By default, shouldComponentUpdate always returns true, so if a component re-renders, meaning you change state or props for that component, your render method is called again, and then all the child components (unless shouldComponentUpdate has been overridden) will also in turn have their render methods called. This will happen regardless of whether or not the props are the same. In fact, I often do this at the top, just calling setState with the same props (to a mutable object) to kick off another render.
This is all just JavaScript though and so is very fast. React is then mapping these elements to DOM nodes (which is slow). For that, it uses a very smart diffing algorithm to determine which DOM nodes need to be changed. (Maybe that's your definition of re-render.) So only the DOM elements that have actually changed get touched.
You can, if you want, use the PureRenderMixin to make React only re-render if the props or state actually change. The mixin just leverages shouldComponentUpdate to do this. This can be a bit of a can of worms though, so I kept this out of my beginnerish post.