0

I am reading react.js official docs. Here is one of them.

I am confused about this paragraph:

setState() will always lead to a re-render unless shouldComponentUpdate() returns false. If mutable objects are being used and conditional rendering logic cannot be implemented in shouldComponentUpdate(), calling setState() only when the new state differs from the previous state will avoid unnecessary re-renders.

Question: Why calling setState() will avoid unnecessary re-renders if mutable objects are being used and conditional rendering logic cannot be implemented in shouldComponentUpdate()?

Henrik Andersson
  • 45,354
  • 16
  • 98
  • 92
krave
  • 1,629
  • 4
  • 17
  • 36

3 Answers3

2

shouldComponentUpdate deep-dive might help you

  • Calling setState() will always trigger a re-render of the component(unless you have defined shouldComponentUpdate()). But keeping performance and efficiency in mind, we want the component to re-render only if the state value has actually changed.
  • This is where shouldComponentUpdate() lifecycle method comes into play. In this method, a check can be done to determine whether the state value has changed. If state has changed, returns true and the component re-renders.
  • Mutable objects refer to Arrays, objects etc in javascript. Numbers and Strings are immutable.

Mutable object example:

const a = [1,2]; // memory address of a is 0xff456e
a.push(3); // memory address of a is 0xff456e(same)

Immutable object example:

 let b = 'Hello'; // memory address of b is 0xee789e
 b = 'World'; // memory address of b is 0xee789f(different because its a new object created with value 'World')

  • If your component is a PureComponent, then react by default will define the shouldComponentUpdate() to reduce unnecessary re-renders. But you need to use immutable objects for that to work correctly(i.e create a new array or object manually and assign to your state, else your component won't re-render correctly).

  • So, the point they are making is this : Don't call setState() unless the state value has actually changed if your using a normal react component without a shouldComponentUpdate() check to avoid situations like this:

 this.setState({ items: [1, 2, 3] }); // re-render once
 // lot of code goes here
 this.setState({ items: [1, 2, 3] }); // re-render twice

Note: Although the value of items is unchanged, there is a wasteful re-render of the component caused as shown above. So, avoid setting state if there is no change of value.

Anu
  • 1,079
  • 8
  • 12
0

I think you read that wrong.

It's a two term conditional:

IF

mutable objects are being used

AND

conditional rendering logic cannot be implemented in shouldComponentUpdate()

THEN

[you should call] setState() only when the new state differs from the previous state [so it] will avoid unnecessary re-renders.

(Alteration by me are in brackets.)

Basically, it means that it's up to you to test if you should call setState if you can't rely on React's internal tests due to technical limitations on your side.

ChrisR
  • 3,922
  • 1
  • 14
  • 24
  • Thank you for prompt answer! If my understanding is correct, `mutable objects` means state literal objects. Generally, we can rely on `shouldComponentUpdate()` to let react judge if the component need re-rendering. If we can not rely on it, we should do some check stuff by ourselves. Am I correct? Do you have some examples about situations where we can not depend on `shouldComponentUpdate()` ? – krave May 04 '18 at 09:57
0

The doc wanted to say that in the following conditions, the re-render will not happen:

  1. If shouldComponentUpdate hook returns false.

  2. If mutable objects are being used.

  3. If some conditional logic is not used for re-render like force update inside shouldComponentUpdate hook.

  4. If the effect of calling setState method only change the previous state value.

BTW, I'm still not satisfied that I couldn't make clear enough. :(:

Bhojendra Rauniyar
  • 83,432
  • 35
  • 168
  • 231