Хуки — нововведение в React 16.8, которое позволяет использовать состояние и другие возможности React без написания классов.
\nХук эффекта даёт вам возможность выполнять побочные эффекты в функциональном компоненте:
\nimport React, { useState, useEffect } from 'react';\nfunction Example() {\n const [count, setCount] = useState(0);\n\n // Аналогично componentDidMount и componentDidUpdate: useEffect(() => { // Обновляем заголовок документа с помощью API браузера document.title = `Вы нажали ${count} раз`; });\n return (\n <div>\n <p>Вы нажали {count} раз</p>\n <button onClick={() => setCount(count + 1)}>\n Нажми на меня\n </button>\n </div>\n );\n}Этот фрагмент основан на примере со счётчиком из предыдущей страницы, только мы добавили новую функциональность: мы изменяем заголовок документа на пользовательское сообщение, которое также содержит количество нажатий кнопки.
\nПобочными эффектами в React-компонентах могут быть: загрузка данных, оформление подписки и изменение DOM вручную. Неважно, называете ли вы эти операции «побочными эффектам» (или просто «эффектами») или нет, скорее всего вам доводилось ранее использовать их в своих компонентах.
\n\n\nСовет
\nЕсли вам знакомы классовые методы жизненного цикла React, хук
\nuseEffectпредставляет собой совокупность методовcomponentDidMount,componentDidUpdate, иcomponentWillUnmount.
Существует два распространённых вида побочных эффектов в компонентах React: компоненты, которые требуют и не требуют сброса. Давайте рассмотрим оба примера более детально.
\nИногда мы хотим выполнить дополнительный код после того, как React обновил DOM. Сетевые запросы, изменения DOM вручную, логирование — всё это примеры эффектов, которые не требуют сброса. После того, как мы запустили их, можно сразу забыть о них, ведь больше никаких дополнительных действий не требуется. Давайте сравним, как классы и хуки позволяют нам реализовывать побочные эффекты.
\nВ классовых React-компонентах метод render сам по себе не должен вызывать никаких побочных эффектов. Он не подходит для этих целей, так как в основном мы хотим выполнить наши эффекты после того, как React обновил DOM.
Вот почему в классах React мы размещаем побочные эффекты внутрь componentDidMount и componentDidUpdate. Возвращаясь к нашему примеру, здесь представлен счётчик, реализованный с помощью классового React-компонента. Он обновляет заголовок документа сразу же после того, как React вносит изменения в DOM:
class Example extends React.Component {\n constructor(props) {\n super(props);\n this.state = {\n count: 0\n };\n }\n\n componentDidMount() { document.title = `Вы нажали ${this.state.count} раз`; } componentDidUpdate() { document.title = `Вы нажали ${this.state.count} раз`; }\n render() {\n return (\n <div>\n <p>Вы нажали {this.state.count} раз</p>\n <button onClick={() => this.setState({ count: this.state.count + 1 })}>\n Нажми на меня\n </button>\n </div>\n );\n }\n}Обратите внимание, что нам приходится дублировать наш код между этими классовыми методами жизненного цикла.
\nЭто всё потому, что во многих случаях, мы хотим выполнять одни и те же побочные эффекты вне зависимости от того, был ли компонент только что смонтирован или обновлён. Мы хотим чтобы они выполнялись после каждого рендера — но у классовых React-компонентов нет таких встроенных методов. Мы могли бы вынести этот метод отдельно, но нам бы всё равно пришлось бы вызывать его в двух местах.
\nА сейчас, давайте рассмотрим, как мы можем сделать то же самое с использованием хука useEffect.
Мы уже рассматривали этот пример немного ранее, но давайте разберём его более подробно:
\nimport React, { useState, useEffect } from 'react';\nfunction Example() {\n const [count, setCount] = useState(0);\n\n useEffect(() => { document.title = `Вы нажали ${count} раз`; });\n return (\n <div>\n <p>Вы нажали {count} раз</p>\n <button onClick={() => setCount(count + 1)}>\n Нажми на меня\n </button>\n </div>\n );\n}Что же делает useEffect? Используя этот хук, вы говорите React сделать что-то после рендера. React запомнит функцию (то есть «эффект»), которую вы передали и вызовет её после того, как внесёт все изменения в DOM. В этом эффекте мы устанавливаем заголовок документа, но мы также можем выполнить запрос данных или вызвать какой-нибудь императивный API.
Почему же мы вызываем useEffect непосредственно внутри компонента? Это даёт нам доступ к переменной состояния count (или любым другим пропсам) прямиком из эффекта. Нам не нужен специальный API для доступа к этой переменной — она уже находится у нас в области видимости функции. Хуки используют JavaScript-замыкания, и таким образом, им не нужен специальный API для React, поскольку сам JavaScript уже имеет готовое решение для этой задачи.
Выполняется ли useEffect после каждого рендера? Разумеется! По умолчанию он будет выполняться после каждого рендера и обновления. Мы рассмотрим, как настраивать это немного позже. Вместо того, чтобы воспринимать это с позиции «монтирования» и «обновления», мы советуем просто иметь в виду, что эффекты выполняются после каждого рендера. React гарантирует, что он запустит эффект только после того, как DOM уже обновился.
Мы узнали немного больше о принципе работы эффектов и теперь этот код уже вовсе не кажется таким непонятным:
\nfunction Example() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n document.title = `Вы нажали ${count} раз`;\n });\n}Мы объявляем переменную состояния count и говорим React, что мы хотим использовать эффект. Далее, мы передаём функцию в хук useEffect. Эта функция как раз и будет нашим эффектом. Внутри этого эффекта мы устанавливаем заголовок документа, используя API браузера document.title. Мы можем получать доступ к актуальной переменной count изнутри эффекта, так как он находится в области видимости нашей функции. Когда React рендерит наш компонент, он запоминает эффект, который мы использовали, и запускает его после того, как обновит DOM. Это будет происходить при каждом рендере, в том числе и при первоначальном.
Опытные JavaScript-разработчики могут подметить, что функция, которую мы передаём в useEffect, будет меняться при каждом рендере. На самом деле, это было сделано преднамеренно. Это как раз то, что даёт нам возможность получать актуальную версию переменной count изнутри эффекта, не беспокоясь о том, что её значение устареет. Каждый раз при повторном рендере, мы ставим в очередь новый эффект, который заменяет предыдущий. В каком-то смысле, это включает поведение эффектов как часть результата рендера, то есть каждый эффект «принадлежит» определённому рендеру. Мы расскажем о преимуществах данного подхода далее на этой странице.
\n\nСовет
\nВ отличие от
\ncomponentDidMountилиcomponentDidUpdate, эффекты, запланированные с помощьюuseEffect, не блокируют браузер при попытке обновить экран. Ваше приложение будет быстрее реагировать на действия пользователя, даже когда эффект ещё не закончился. Большинству эффектов не нужно работать в синхронном режиме. Есть редкие случаи, когда им всё же нужно это делать (например, измерять раскладку), но для этого мы разработали специальный хукuseLayoutEffectс точно таким же API, как и уuseEffect.
Ранее мы рассмотрели побочные эффекты, которые не требуют сброса. Однако, есть случаи, когда сброс всё же необходим. Например, нам может потребоваться установить подписку на какой-нибудь внешний источник данных. В этом случае очень важно выполнять сброс, чтобы не случилось утечек памяти! Давайте сравним, как мы можем это реализовать с помощью классов и хуков.
\nВ React-классе, вы, как правило, оформили бы подписку в componentDidMount и отменили бы её в componentWillUnmount. Например, предположим, что у нас есть некий модуль ChatAPI, с помощью которого мы можем подписаться на статус друга в сети. Вот как мы бы подписались и отобразили бы статус, используя класс:
class FriendStatus extends React.Component {\n constructor(props) {\n super(props);\n this.state = { isOnline: null };\n this.handleStatusChange = this.handleStatusChange.bind(this);\n }\n\n componentDidMount() { ChatAPI.subscribeToFriendStatus( this.props.friend.id, this.handleStatusChange ); } componentWillUnmount() { ChatAPI.unsubscribeFromFriendStatus( this.props.friend.id, this.handleStatusChange ); } handleStatusChange(status) { this.setState({ isOnline: status.isOnline }); }\n render() {\n if (this.state.isOnline === null) {\n return 'Загрузка...';\n }\n return this.state.isOnline ? 'В сети' : 'Не в сети';\n }\n}Обратите внимание, что componentDidMount и componentWillUnmount по сути содержат идентичный код. Методы жизненного цикла вынуждают нас разбивать эту логику, хоть и фактически код обоих методов относится к одному и тому же эффекту.
\n\nПримечание
\nВы могли заметить, что для правильной работы, нашему компоненту также нужен
\ncomponentDidUpdate. Мы вернёмся к этому моменту ниже на этой странице.
Давайте рассмотрим, как этот компонент будет выглядеть, если написать его с помощью хуков.
\nВы должно быть подумали, что нам потребуется отдельный эффект для выполнения сброса. Так как код для оформления и отмены подписки тесно связан с useEffect, мы решили объединить их. Если ваш эффект возвращает функцию, React выполнит её только тогда, когда наступит время сбросить эффект.
import React, { useState, useEffect } from 'react';\n\nfunction FriendStatus(props) {\n const [isOnline, setIsOnline] = useState(null);\n\n useEffect(() => { function handleStatusChange(status) { setIsOnline(status.isOnline); } ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange); // Указываем, как сбросить этот эффект: return function cleanup() { ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange); }; });\n if (isOnline === null) {\n return 'Загрузка...';\n }\n return isOnline ? 'В сети' : 'Не в сети';\n}Зачем мы вернули функцию из нашего эффекта? Это необязательный механизм сброса эффектов. Каждый эффект может возвратить функцию, которая сбросит его. Это даёт нам возможность объединить вместе логику оформления и отмены подписки. Они, всё-таки, часть одного и того же эффекта!
\nКогда именно React будет сбрасывать эффект? React будет сбрасывать эффект перед тем, как компонент размонтируется. Однако, как мы уже знаем, эффекты выполняются не один раз, а при каждом рендере. Вот почему React также сбрасывает эффект из предыдущего рендера, перед тем, как запустить следующий. Мы рассмотрим почему это позволяет избежать багов и как отказаться от этой логики, если это вызывает проблемы с производительностью далее.
\n\n\nСовет
\nНам не нужно возвращать именованную функцию из эффекта. Мы назвали её «сбросом», чтобы объяснить её предназначение. Вы можете по желанию возвратить стрелочную функцию или назвать её как-то по-другому.
\n
Мы узнали, что с помощью useEffect, мы можем вызывать разные побочные эффекты после того, как компонент отрендерится. Некоторым эффектам нужен сброс, поэтому они возвращают соответствующую функцию.
useEffect(() => {\n function handleStatusChange(status) {\n setIsOnline(status.isOnline);\n }\n\n ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);\n return () => {\n ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);\n };\n });В некоторых эффектах нет этапа сброса, поэтому они не возвращают ничего.
\n useEffect(() => {\n document.title = `Вы нажали ${count} раз`;\n });Хук эффекта покрывает оба сценария единым API.
\nЕсли вы чувствуете, что вы достаточно разобрались с тем, как работает хук эффекта, вы можете отправиться на страницу о правилах хуков прямо сейчас.
\nСейчас, давайте углубимся в некоторые особенности хука useEffect, о которых опытные пользователи React наверняка уже задумались. Пожалуйста, не заставляйте себя углубляться в эти особенности прямо сейчас. Вы можете сперва закрепить выше пройденный материал и вернуться сюда позже в любой момент.
Один из ключевых моментов, которые мы описали в мотивации, приводит аргументы о том, что в отличии от хуков, классовые методы жизненного цикла часто содержат логику, которая никак между собой не связана, в то время как связанная логика, разбивается на несколько методов. Далее мы приведём пример компонента, который объединяет в себе логику счётчика и индикатора статуса нашего друга из предыдущих примеров:
\nclass FriendStatusWithCounter extends React.Component {\n constructor(props) {\n super(props);\n this.state = { count: 0, isOnline: null };\n this.handleStatusChange = this.handleStatusChange.bind(this);\n }\n\n componentDidMount() {\n document.title = `Вы нажали ${this.state.count} раз`;\n ChatAPI.subscribeToFriendStatus(\n this.props.friend.id,\n this.handleStatusChange\n );\n }\n\n componentDidUpdate() {\n document.title = `Вы нажали ${this.state.count} раз`;\n }\n\n componentWillUnmount() {\n ChatAPI.unsubscribeFromFriendStatus(\n this.props.friend.id,\n this.handleStatusChange\n );\n }\n\n handleStatusChange(status) {\n this.setState({\n isOnline: status.isOnline\n });\n }\n // ...Обратите внимание, что логика, которая устанавливает document.title разбита между componentDidMount и componentDidUpdate. Логика подписки также раскидана между componentDidMount и componentWillUnmount. А метод componentDidMount включает в себя логику для обеих задач.
Как же можно решить эту проблему с помощью хуков? Точно так же, как вы можете использовать хук состояния более одного раза, вы можете использовать и несколько эффектов. Это даёт нам возможность разделять разную несвязанную между собой логику между разными эффектами.
\nfunction FriendStatusWithCounter(props) {\n const [count, setCount] = useState(0);\n useEffect(() => { document.title = `Вы нажали ${count} раз`;\n });\n\n const [isOnline, setIsOnline] = useState(null);\n useEffect(() => { function handleStatusChange(status) {\n setIsOnline(status.isOnline);\n }\n\n ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);\n return () => {\n ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);\n };\n });\n // ...\n}С помощью хуков, мы можем разделить наш код основываясь на том, что он делает, а не по принципам методов жизненного цикла. React будет выполнять каждый используемый эффект в компоненте, согласно порядку их объявления.
\nЕсли вы привыкли пользоваться классами, вам может быть не совсем ясно, почему этап сброса эффекта происходит после каждого последующего рендера, а не один лишь раз во время размонтирования. Давайте рассмотрим на практике, почему такой подход помогает создавать компоненты с меньшим количеством багов.
\nРанее на этой странице, мы рассматривали пример с компонентом FriendStatus, который отображает в сети наш друг или нет. Наш класс берёт friend.id из this.props, подписывается на статус друга после того, как компонент смонтировался, и отписывается во время размонтирования.
componentDidMount() {\n ChatAPI.subscribeToFriendStatus(\n this.props.friend.id,\n this.handleStatusChange\n );\n }\n\n componentWillUnmount() {\n ChatAPI.unsubscribeFromFriendStatus(\n this.props.friend.id,\n this.handleStatusChange\n );\n }Но что же произойдёт, если проп friend поменяется, пока компонент все ещё находится на экране? Наш компонент будет отображать статус в сети уже какого-нибудь другого друга. Это как раз таки баг. Это также может привести к утечке памяти или вообще к вылету нашего приложения при размонтировании, так как метод отписки будет использовать неправильный ID друга, от которого мы хотим отписаться.
В классовом компоненте нам бы пришлось добавить componentDidUpdate, чтобы решить эту задачу:
componentDidMount() {\n ChatAPI.subscribeToFriendStatus(\n this.props.friend.id,\n this.handleStatusChange\n );\n }\n\n componentDidUpdate(prevProps) { // Отписаться от предыдущего friend.id ChatAPI.unsubscribeFromFriendStatus( prevProps.friend.id, this.handleStatusChange ); // Подписаться на следующий friend.id ChatAPI.subscribeToFriendStatus( this.props.friend.id, this.handleStatusChange ); }\n componentWillUnmount() {\n ChatAPI.unsubscribeFromFriendStatus(\n this.props.friend.id,\n this.handleStatusChange\n );\n }Не использовать componentDidUpdate надлежащим образом — это один из самых распространённых источников багов в приложениях React.
Теперь давайте рассмотрим версию этого же компонента, но уже написанного с использованием хуков:
\nfunction FriendStatus(props) {\n // ...\n useEffect(() => {\n // ...\n ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);\n return () => {\n ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);\n };\n });Этого бага в данном компоненте нет. (Но мы и не изменили там ничего)
\nЗдесь нет никакого особого кода для решения проблем с обновлениями, так как useEffect решает их по умолчанию. Он сбрасывает предыдущие эффекты прежде чем выполнить новые. Чтобы показать это на практике, давайте рассмотрим последовательность подписок и отписок, которые этот компонент может выполнить в течение некоторого времени.
// Монтируем с пропсами { friend: { id: 100 } } \nChatAPI.subscribeToFriendStatus(100, handleStatusChange); // Выполняем первый эффект\n\n// Обновляем с пропсами { friend: { id: 200 } }\nChatAPI.unsubscribeFromFriendStatus(100, handleStatusChange); // Сбрасываем предыдущий эффект\nChatAPI.subscribeToFriendStatus(200, handleStatusChange); // Выполняем следующий эффект\n\n// Обновляем с пропсами { friend: { id: 300 } }\nChatAPI.unsubscribeFromFriendStatus(200, handleStatusChange); // Сбрасываем предыдущий эффект\nChatAPI.subscribeToFriendStatus(300, handleStatusChange); // Выполняем следующий эффект\n\n// Размонтируем\nChatAPI.unsubscribeFromFriendStatus(300, handleStatusChange); // Сбрасываем последний эффектЭта логика по умолчанию гарантирует согласованность выполняемых нами действий и исключает баги, распространённые в классовых компонентах из-за упущенной логики обновления.
\nВ некоторых случаях сброс или выполнение эффекта при каждом рендере может вызвать проблему с производительностью. В классовых компонентах, мы можем решить это используя дополнительное сравнение prevProps или prevState внутри componentDidUpdate:
componentDidUpdate(prevProps, prevState) {\n if (prevState.count !== this.state.count) {\n document.title = `Вы нажали ${this.state.count} раз`;\n }\n}Эту логику приходится использовать довольно часто, поэтому мы решили встроить её в API хука useEffect. Вы можете сделать так, чтобы React пропускал вызов эффекта, если определённые значения остались без изменений между последующими рендерами. Чтобы сделать это, передайте массив в useEffect вторым необязательным аргументом.
useEffect(() => {\n document.title = `Вы нажали ${count} раз`;\n}, [count]); // Перезапускать эффект только если count поменялсяВ этом примере, мы передаём [count] вторым аргументом. Что это вообще значит? Это значит, что если count будет равен 5 и наш компонент повторно рендерится с тем же значением count = 5, React сравнит [5] из предыдущего рендера и [5] из следующего рендера. Так как, все элементы массива остались без изменений (5 === 5), React пропустит этот эффект. Это и есть оптимизация данного процесса.
Когда при следующем рендере наша переменная count обновится до 6, React сравнит элементы в массиве [5] из предыдущего рендера и элементы массива [6] из следующего рендера. На этот раз, React выполнит наш эффект, так как 5 !== 6. Если у вас будет несколько элементов в массиве, React будет выполнять наш эффект, в том случае, когда хотя бы один из них будет отличаться.
Это также работает для эффектов с этапом сброса:
\nuseEffect(() => {\n function handleStatusChange(status) {\n setIsOnline(status.isOnline);\n }\n\n ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);\n return () => {\n ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);\n };\n}, [props.friend.id]); // Повторно подписаться, только если props.friend.id изменилсяВ будущем, второй аргумент возможно будет добавляться автоматически с помощью трансформации во время выполнения.
\n\n\nПримечание
\nЕсли вы хотите использовать эту оптимизацию, обратите внимание на то, чтобы массив включал в себя все значения из области видимости компонента (такие как пропсы и состояние), которые могут изменяться с течением времени, и которые будут использоваться эффектом. В противном случае, ваш код будет ссылаться на устаревшее значение из предыдущих рендеров. Отдельные страницы документации рассказывают о том, как поступить с функциями и что делать с часто изменяющимися массивами.
\nЕсли вы хотите запустить эффект и сбросить его только один раз (при монтировании и размонтировании), вы можете передать пустой массив (
\n[]) вторым аргументом. React посчитает, что ваш эффект не зависит от каких-либо значений из пропсов или состояния и поэтому не будет выполнять повторных рендеров. Это не обрабатывается как особый случай — он напрямую следует из логики работы массивов зависимостей.Если вы передадите пустой массив (
\n[]), пропсы и состояние внутри эффекта всегда будут иметь значения, присвоенные им изначально. Хотя передача[]ближе по модели мышления к знакомымcomponentDidMountиcomponentWillUnmount, обычно есть более хорошие способы избежать частых повторных рендеров. Не забывайте, что React откладывает выполнениеuseEffect, пока браузер не отрисует все изменения, поэтому выполнение дополнительной работы не является существенной проблемой.Мы рекомендуем использовать правило
\nexhaustive-deps, входящее в наш пакет правил линтераeslint-plugin-react-hooks. Оно предупреждает, когда зависимости указаны неправильно и предлагает исправление.
Поздравляем! Это была длинная страница, но мы надеемся, что под конец, у нас получилось ответить на все ваши вопросы по поводу работы эффектов. Вы уже узнали о хуке состояния и о хуке эффекта, и теперь есть очень много вещей, которые вы можете делать, объединив их вместе. Они покрывают большинство задач решаемых классами. В остальных случаях, вам могут пригодиться дополнительные хуки.
\nМы также узнали, как хуки избавляют от проблем описанных в мотивации. Мы увидели, как с помощью сброса эффектов нам удаётся избежать повторов кода в componentDidUpdate и componentWillUnmount, объединить связанный код вместе и защитить наш код от багов. Мы также рассмотрели, как можно разделять наши эффекты по смыслу и назначению, что ранее было невозможно в классах.
На этом этапе, вы, возможно, задаётесь вопросом, как хуки работают в целом. Как React понимает, какая переменная состояния соответствует какому вызову useState между повторными рендерами? Как React «сопоставляет» предыдущие и следующие эффекты при каждом обновлении? На следующей странице, мы узнаем о правилах хуков, так как они являются залогом правильной работы хуков.