Доброго времени суток, друзья!
Представляю вашему вниманию перевод небольшой заметки Kent C. Dodds, в которой он делится своими соображениями относительно правильного использования хука useEffect.
Я обучил React тысячи разработчиков. Как до, так и после релиза
хуков. Одной из вещей, которые я заметил, является не очень четкое понимание
назначения и механизма работы хука useEffect. В этой статье я хочу немного об этом рассказать.
Никакого отношения к стадиям жизненного цикла синхронизация дополнительных эффектов
Разработчики, которые имеют опыт работы с классовыми компонентами и стадиями
жизненного цикла, такими как constructor, componentDidMount,
componentDidUpdate и componentWillUnmount, иногда пытаются реализовать
аналогичное поведение в функциональных компонентах с помощью хуков. Это большая
ошибка. Позвольте мне это продемонстрировать. Вот пример забавного
пользовательского интерфейса:
Вот реализация компонента DogInfo с помощью классов:
class DogInfo extends React.Component { controller = null; state = { dog: null }; fetchDog() { this.controller?.abort(); this.controller = new AbortController(); getDog(this.props.dogId, { signal: this.controller.signal }).then( (dog) => { this.setState({ dog }); }, (error) => { // обработка ошибок } ); } componentDidMount() { this.fetchDog(); } componentDidUpdate(prevProps) { // обработка изменения dogId if (prevProps.dogId !== this.props.dogId) { this.fetchDog(); } } componentWillUnmount() { // отмена запроса this.controller?.abort(); } render() { return <div>{/* рендеринг информации о собаке */}</div>; } }
Это стандартный компонент для такого вида интеракции. В нем
используются стадии жизненного цикла constructor, componentDidMount,
componentDidUpdate и componentWillUnmount. Вот что получится, если мы
обернем эти стадии в хуки:
function DogInfo({ dogId }) { const controllerRef = React.useRef(null); const [dog, setDog] = React.useState(null); function fetchDog() { controllerRef.current?.abort(); controllerRef.current = new AbortController(); getDog(dogId, { signal: controllerRef.current.signal }).then( (d) => setDog(d), (er) => { // обработка ошибок } ); } // didMount React.useEffect(() => { fetchDog(); // eslint-disable-next-line react-hooks/exhaustive-deps }, []); // didUpdate const prevDogId = usePrevious(dogId); useUpdate(() => { if (prevDogId !== dogId) { fetchDog(); } }); // willUnmount React.useEffect(() => { return () => { controllerRef.current?.abort(); }; }, []); return <div>{/* рендеринг информации о собаке */}</div>; } function usePrevious(value) { const ref = useRef(); useEffect(() => { ref.current = value; }, [value]); return ref.current; }
Здесь имеется некоторая несогласованность между хуками. Если бы они
предназначались для использования таким образом, я тоже был бы их противником.
Но правда в том, что useEffect это не стадия жизненного цикла. Это механизм
синхронизации дополнительных эффектов с состоянием приложения. В
приведенном примере наша задача состоит в том, чтобы запрашивать информацию о
собаке при изменении dogId. Учитывая это, useEffect становится намного проще:
function DogInfo({ dogId }) { const [dog, setDog] = useState(null); useEffect(() => { const controller = new AbortController(); getDog(dogId, { signal: controller.signal }).then( (d) => setDog(d), (er) => { // обработка ошибок } ); return () => controller.abort(); }, [dogId]); return <div>{/* рендеринг информации о собаке */}</div>; }
Это выглядит намного лучше, не так ли? Когда команда React представила хуки, их
целью являлось не упрощение использования стадий жизненного цикла в
функциональных компонентах, а улучшение ментальной модели относительно дополнительных эффектов приложения. И они этого достигли.
Запомните высказывание Ryan Florence:
Вопрос не в том, когда запускать эффект, вопрос в том, с каким состоянием
он должен синхронизироваться
useEffect(fn) // все состояния
useEffect(fn, []) // отсутствие состояний
useEffect(fn, [these, states]) // указанные состояния
Могу я игнорировать eslint-plugin-react-hooks/exhaustive-deps?
Ну, технически да. И иногда для этого существуют хорошие причины. Однако, в
большинстве случаев это является плохой идеей, игнорирование этого правила почти наверняка приведет к ошибкам. Обычно, люди после этого говорят: Но я только
хотел, чтобы это запускалось после рендеринга!. Вот опять. Думать о хуках в
категориях жизненного цикла неправильно. Если ваш колбэк в useEffect имеет
зависимость, необходимо убедиться, что он выполняется при каждом изменении
этой зависимости. В противном случае, эффект не будет синхронизирован с
состоянием приложения. Короче говоря, у вас будут проблемы. Не игнорируйте
данное правило.
Один большой useEffect
Честно говоря, я давно такого не видел. Но такое порой все-таки случается. То,
что мне действительно нравится в useEffect, так это возможность разделения задачи на любое количество подзадач. Вот простой пример:
Вот некоторый всевдокод для этого демо:
class ChatFeed extends React.Component { componentDidMount() { this.subscribeToFeed(); this.setDocumentTitle(); this.subscribeToOnlineStatus(); this.subscribeToGeoLocation(); } componentWillUnmount() { this.unsubscribeFromFeed(); this.restoreDocumentTitle(); this.unsubscribeFromOnlineStatus(); this.unsubscribeFromGeoLocation(); } componentDidUpdate(prevProps, prevState) { // ... сранение пропсов, повторной подписки и т.д. } render() { return <div>{/* интерфейс чата */}</div>; } }
Видите эти 4 задачи? Они смешаны. Что, если вы захотите поделиться частью функционала? Я имею ввиду, что пропсы рендеринга отличная вещь, но хуки
все же лучше. Я видел, как некоторые люди создают огромный useEffect, отвечающий
за все:
function ChatFeed() { React.useEffect(() => { // подписка на ленту // установка заголовка документа // перевод статуса в онлайн // определения местоположения return () => { // отписка от ленты // восстановление заголовка // перевод статуса в офлайн // отключение определения местоположения }; }); return <div>{/* интерфейс чата */}</div>; }
Но это делает колбэк очень сложным. Предлагаю другой подход. Не забывайте, что
вы можете разделять логику между разными хуками:
function ChatFeed() { React.useEffect(() => { // подписка на ленту return () => { // отписка от ленты }; }); React.useEffect(() => { // установка заголовка документа return () => { // восстановление заголовка }; }); React.useEffect(() => { // перевод статуса в онлайн return () => { // перевод статуса в офлайн }; }); React.useEffect(() => { // определения местоположения return () => { // отключение определения местоположения }; }); return <div>{/* интерфейс чата */}</div>; }
Самодостаточность хуков дает массу преимуществ.
Внешние функции
Я видел такое несколько раз. Позвольте мне просто привести код до и после:
// до. Не делайте так function DogInfo({ dogId }) { const [dog, setDog] = React.useState(null); const controllerRef = React.useRef(null); const fetchDog = React.useCallback((dogId) => { controllerRef.current?.abort(); controllerRef.current = new AbortController(); return getDog(dogId, { signal: controller.signal }).then( (d) => setDog(d), (error) => { // обработка ошибок } ); }, []); React.useEffect(() => { fetchDog(dogId); return () => controller.current?.abort(); }, [dogId, fetchDog]); return <div>{/* рендеринг информации о собаках */}</div>; }
Мы уже видели, как можно упростить этот код, но давайте взглянем на него еще раз:
function DogInfo({ dogId }) { const [dog, setDog] = React.useState(null); React.useEffect(() => { const controller = new AbortController(); getDog(dogId, { signal: controller.signal }).then( (d) => setDog(d), (error) => { // обработка ошибок } ); return () => controller.abort(); }, [dogId]); return <div>{/* рендеринг информации о собаках */}</div>; }
Я пытаюсь сказать, что определение функции за пределами колбэка useEffect это плохая идея. Поскольку такая функция является внешней по отношению к useEffect, нам приходится добавлять ее в список зависимостей. Также нам приходится кэшировать ее во избежание бесконечного цикла. Кроме того, мы вынуждены создавать ref для контроллера.
Запомните: при необходимости определения функции, вызываемой в эффекте, определяйте ее внутри колбэка данного эффекта, а не за его пределами.
Заключение
Когда Dan Abramov представил хуки, такие как useEffect, он сравнил компоненты с атомами, а хуки с электронами. Хуки представляют собой низкоуровневые примитивы, и именно это делает их такими мощными. Красота этих примитивов заключается в абстрагировании стадий жизненного цикла, с которыми мы имели дело раньше. С момента релиза хуков мы наблюдаем взрыв инноваций и появление хороших идей и библиотек на основе этих примитивов, что помогает нам, как разработчикам, создавать более качественные приложения.