Думайте о 'setState' в официальном документе React

Question

Я читаю официальные документы response.js. Вот один из них.

Я запутался в этом абзаце:

setState () всегда приведет к повторному рендерингу, если только shouldComponentUpdate () возвращает false. Если изменяемые объекты находятся в используемая и условная логика рендеринга не может быть реализована в shouldComponentUpdate (), вызывающий setState () только при новом состоянии отличается от предыдущего состояния позволит избежать ненужных повторных рендеров.

Вопрос: Почему вызов setState() позволит избежать ненужных повторных визуализаций, если используются изменяемые объекты и логика условного рендеринга не может быть реализована в shouldComponentUpdate()?

Answer 1

Док хотел сказать, что при следующих условиях повторного рендеринга не произойдет:

1. Если хук shouldComponentUpdate возвращает false.

2. Если используются изменяемые объекты.

3. Если некоторая условная логика не используется для повторного рендеринга, например, принудительное обновление внутри ловушки shouldComponentUpdate.

4. Если эффект вызова метода setState изменяет только предыдущее значение состояния.

Кстати, я до сих пор не удовлетворен тем, что не смог прояснить достаточно. (:

Answer 2

shouldComponentUpdate глубокое погружение может помочь вам

• Вызов setState () всегда вызывает повторную визуализацию компонента (если вы не определили shouldComponentUpdate ()). Но, помня о производительности и эффективности, мы хотим, чтобы компонент повторно рендерился, только если значение состояния действительно изменилось.
• Именно здесь вступает в игру метод жизненного цикла shouldComponentUpdate (). В этом методе можно проверить, изменилось ли значение состояния. Если состояние изменилось, возвращает true и компонент повторно отрисовывается.
• Изменяемые объекты ссылаются на массивы, объекты и т. Д. В javascript. Числа и строки неизменны.

Пример изменяемого объекта:

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

Пример неизменяемого объекта:

 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')

• Если ваш компонент представляет собой PureComponent, то по умолчанию для реакции будет определен shouldComponentUpdate (), чтобы уменьшить ненужные повторные рендеры. Но вам нужно использовать неизменяемые объекты, чтобы это работало правильно (т.е. создайте новый массив или объект вручную и присвойте его состоянию, иначе ваш компонент не будет корректно перерисовываться).

• Итак, они делают следующее замечание: Не вызывайте setState (), если только значение состояния не изменилось , если вы используете normal реагирующий компонент без проверка shouldComponentUpdate (), чтобы избежать таких ситуаций:

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

Примечание. Несмотря на то, что стоимость предметов не изменилась, происходит расточительный повторный рендеринг компонента, как показано выше. Поэтому избегайте установки состояния, если нет изменения значения.

Answer 3

Я думаю, что вы прочитали это неправильно.

Это условный термин:

IF

используются изменяемые объекты

И

Логика условного рендеринга не может быть реализована в shouldComponentUpdate ()

ТО

[Вы должны вызывать] setState () только тогда, когда новое состояние отличается от предыдущего состояния [поэтому оно] позволит избежать ненужных повторных визуализаций.

(Переделка мной в скобках.)

По сути, это означает, что вы должны проверить, следует ли вам звонить setState, если вы не можете положиться на внутренние тесты React из-за технических ограничений на вашей стороне.