Обновить жизненный цикл компонента React на основе классов

Жизненный цикл обновления

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

Когда обновляется компонент?

Компонент обновляется при внесении изменений в свойства или состояние компонента. Когда это происходит, компонент повторно оценивается и проходит другой жизненный цикл, нежели жизненный цикл создания.

1. getDerivedStateFromProps

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

Он проверяет, были ли внесены какие-либо изменения в свойства, и извлекает новое состояние из этих изменений. Как и в жизненном цикле создания, этот крючок жизненного цикла требуется редко, поскольку, скорее всего, будет доступно более элегантное решение.

2. shouldComponentUpdate

Эта ловушка жизненного цикла вызывается после getDerivedStateFromProps и перед функцией render и позволяет нам отменить процесс обновления. Его можно использовать, чтобы сообщить React, влияют ли изменения в состоянии или свойствах компонента на вывод компонента. Затем для оптимизации производительности мы можем решить, следует ли React продолжить обновление и повторный рендеринг компонента.

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

React docs рекомендует использовать PureComponent, если вы не уверены, что вручную реализуете shouldComponentUpdate.

3. рендеринг

Затем идет функция render. Если shouldComponentUpdate возвращает false, что означает, что компонент не должен обновляться, функция визуализации не вызывается.

Во время жизненного цикла создания функция рендеринга оценивает весь JSX и рендерит компонент в DOM. Однако во время жизненного цикла обновления после оценки JSX функция рендеринга создает виртуальную DOM и проверяет, нужно ли ей обновить реальную DOM. Если обновление необходимо, вместо обновления всей DOM он сравнивает виртуальную DOM и реальную DOM и вносит изменения только в те части, которые нуждаются в обновлении.

Это означает, что изменение цвета кнопки приведет к обновлению только этой кнопки, а не всей страницы.

4. getSnapshotBeforeUpdate

Хотя getSnapshotBeforeUpdate идет после функции рендеринга в жизненном цикле обновления компонента React, он вызывается прямо перед тем, как какие-либо обновления будут фактически зафиксированы в реальной DOM. Это также крючок жизненного цикла, который не часто используется и в основном используется для операций в последнюю минуту, таких как сбор некоторой информации из DOM перед ее обновлением.

Этот хук получает предыдущее состояние и реквизиты в качестве параметров и может либо возвращать объект моментального снимка, либо значение null. Один из вариантов использования этой ловушки - захват позиции прокрутки на странице перед обновлением модели DOM и установка текущего значения прокрутки на это значение. Это гарантирует, что даже после повторного рендеринга DOM положение прокрутки останется прежним.

Любое значение, возвращаемое getSnapshotBeforeUpdate, передается в качестве параметра в componentDidUpdate.

5. componentDidUpdate

Эта ловушка вызывается после завершения выполнения функции render и обновления DOM. Этот хук вызывается не при первоначальном рендеринге страницы, а при обновлении компонента.

С помощью этого хука можно выполнять асинхронные задачи, такие как выполнение HTTP-запросов. Хотя обновление состояния в этой ловушке не будет блокировать процесс обновления, так как рендеринг завершен, нам все же нужно позаботиться о том, чтобы мы могли закончить бесконечный цикл повторных рендерингов.

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

Этот хук принимает в качестве аргументов предыдущее состояние и реквизиты до обновления компонента. Предыдущие свойства можно сравнить с текущими, чтобы проверить, нужно ли выполнять сетевой запрос, если свойство изменилось. Если ваш компонент реализует редко используемую ловушку жизненного цикла getSnapshotBeforeUpdate (), тогда componentDidUpdate () получит третий аргумент - снимок. Если getSnapshotBeforeUpdate () не реализован, третий аргумент будет неопределенным.

Примечание: если shouldComponentUpdate() возвращает false, componentDidUpdate() не будет вызываться

Подведение итогов

Это хуки жизненного цикла, которые вызываются, когда компонент проходит обновление. В следующей статье мы увидим ловушку useEffect, которую можно использовать в функциональном компоненте вместо этих ловушек жизненного цикла.

Изначально опубликовано в моем блоге.