Хуки — нововведение в React 16.8, которое позволяет использовать состояние и другие возможности React без написания классов.
\nНа этой странице вы найдёте ответы на популярные вопросы о хуках.
\n\nconnect() и React Router?getDerivedStateFromProps?const [thing, setThing] = useState()?Оптимизации производительности
\nshouldComponentUpdate?useCallback?Начиная с релиза 16.8.0, React включает в себя стабильную реализацию хуков для:
\nОбратите внимание, что хуки будут доступны, только если все React-пакеты версии 16.8.0 или выше. Хуки не будут работать, если вы, например, забыли обновить React DOM.
\nReact Native 0.59 и выше поддерживает хуки.
\nНет, мы не собираемся удалять классы из React, поскольку никто не может позволить себе такой глобальный рефакторинг. Мы советуем пробовать хуки только в новом коде.
\nХуки дают новый мощный способ повторного использования кода в компонентах. «Создание пользовательских хуков» даёт представление об их возможностях. Эта статья, написанная одним из участников команды React, описывает новые возможности, которые открывают хуки.
\nХуки — это новый способ использовать возможности React, которые вы уже знаете: состояние, жизненный цикл, контекст и рефы. Хуки не изменили фундаментальную логику React, поэтому ваши знания компонентов, пропсов и нисходящего потока данных остаются актуальными.
\nОднако, хуки — не самая простая часть React. Если вам чего-то не хватает в этой документации, дайте нам знать, и мы постараемся вам помочь.
\nМы рекомендуем начать с использования хуков в новых компонентах, когда вы будете готовы. Убедитесь, что каждый человек в вашей команде поддерживает вас и знаком с документацией. Мы не рекомендуем переписывать все существующие классы на хуки, пока нет необходимости возвращаться к определённому компоненту (например, чтобы исправить баг).
\nВы не можете использовать хуки внутри классового компонента, но вы можете комбинировать классы и функциональные компоненты с хуками в одном дереве. Является ли компонент классовым или функциональным с использованием хуков — неважно, это всего лишь особенность реализации. Мы ожидаем, что в будущем хуки станут главным способом написания React-компонентов.
\nНаша главная задача, чтобы хуки покрывали всю функциональность классов в ближайшем будущем. Пока не существует хуков, реализующих методы жизненного цикла getSnapshotBeforeUpdate, getDerivedStateFromError и componentDidCatch, но мы планируем скоро их добавить.
Хуки появились совсем недавно, и некоторые сторонние библиотеки могут быть ещё не совместимы с ними.
\nКак правило, рендер-пропсы и компоненты высшего порядка рендерят только один дочерний компонент, увеличивая вложенность в дереве, но добавляя потомку новую функциональность. Мы думаем, что хуки — более простой способ сделать это. Оба подхода всё ещё имеют право на жизнь (например, компонент, следящий за скроллом, может иметь проп renderItem или компонент-контейнер может иметь разные рендер-пропсы для различных слотов). Но в большинстве случаев хуки должны помочь уменьшить вложенность компонентов в вашем дереве.
connect() и React Router? Вы можете продолжить использовать тот же самый API, который вы использовали — всё продолжит работать как прежде.
\nНачиная с версии 7.1.0, React Redux поддерживает API хуков и предоставляет такие хуки как useDispatch и useSelector.
Начиная с версии 5.1 появилась поддержка хуков в React Router.
\nВ будущем другие библиотеки могут также начать поддерживать хуки.
\nХуки спроектированы с учётом статической типизации. Так как они являются функциями, их легче правильно типизировать чем, например, компоненты высшего порядка. Последние версии определений типов React для Flow и TypeScript поддерживают хуки.
\nЗаметьте, что пользовательские хуки дают вам возможность накладывать ограничения на API React, если вы хотите типизировать их более строго каким-то образом. React предоставляет примитивы, которые вы можете комбинировать по своему усмотрению даже такими способами, которые и не были изначально предусмотрены.
\nС точки зрения React, компонент, использующий хуки, является обычным компонентом. Если ваш способ тестирования не опирается на внутреннюю реализацию React, тестирование компонентов с хуками не должно отличатся от тестирования других компонентов.
\n\n\nПримечание
\nРецепты Тестирования включают в себя множество примеров, которые вы можете скопировать себе.
\n
Например, у нас есть следующий компонент-счётчик:
\nfunction Example() {\n const [count, setCount] = useState(0);\n useEffect(() => {\n document.title = `Вы кликнули ${count} раз`;\n });\n return (\n <div>\n <p>Вы кликнули {count} раз</p>\n <button onClick={() => setCount(count + 1)}>\n Кликни меня\n </button>\n </div>\n );\n}Мы будем тестировать этот компонент с помощью React DOM. Чтобы убедиться, что поведение совпадает с тем, что случится в браузере, мы обернём код рендера и обновления в вызов ReactTestUtils.act():
import React from 'react';\nimport ReactDOM from 'react-dom';\nimport { act } from 'react-dom/test-utils';import Counter from './Counter';\n\nlet container;\n\nbeforeEach(() => {\n container = document.createElement('div');\n document.body.appendChild(container);\n});\n\nafterEach(() => {\n document.body.removeChild(container);\n container = null;\n});\n\nit('can render and update a counter', () => {\n // Тестируем первый рендер и эффект\n act(() => { ReactDOM.render(<Counter />, container); }); const button = container.querySelector('button');\n const label = container.querySelector('p');\n expect(label.textContent).toBe('Вы кликнули 0 раз');\n expect(document.title).toBe('Вы кликнули 0 раз');\n\n // Тестируем второй рендер и эффект\n act(() => { button.dispatchEvent(new MouseEvent('click', {bubbles: true})); }); expect(label.textContent).toBe('Вы кликнули 1 раз');\n expect(document.title).toBe('Вы кликнули 1 раз');\n});Вызовы act() также запустят эффекты внутри.
Если вам надо протестировать пользовательский хук, вы можете создать компонент в ваших тестах и использовать в нём этот хук. После этого вы можете протестировать сам компонент.
\nДля уменьшения однотипного кода, мы советуем использовать библиотеку React Testing Library. Она была создана для написания тестов, использующих ваши компоненты и имитирующих поведение пользователей в браузере.
\nЗа более подробной информацией обратитесь к Рецептам Тестирования.
\nМы предоставляем плагин к ESLint, который принуждает следовать правилам хуков, чтобы избежать ошибок. Подразумевается, что любая функция, имя который начинается с «use» и заглавной буквы далее, является хуком. Мы понимаем, что это предположение не идеальное, и могут случаться ложные срабатывания. Однако, без этого важного соглашения, было бы невозможно заставить хуки работать хорошо, а более длинные имена могли бы помешать людям начать использовать хуки или следовать соглашению.
Правила линтера проверяют, что:
\nPascalCase (подразумевается, что это компонент), либо внутри другой функции useSomething (подразумевается, что это пользовательский хук).Существует ещё несколько предположений, которые могут измениться по мере того, как мы будем регулировать правила и искать баланс между нахождением ошибок и ложными срабатываниями.
\nconstructor: Функциональному компоненту не нужен конструктор. Вы можете инициализировать состояние, используя вызов useState. Если вычисления состояния затратны, вы можете передать функцию в useState.getDerivedStateFromProps: Запланировать обновление при рендере.shouldComponentUpdate: Смотрите объяснение React.memo ниже.render: Это тело функционального компонента.componentDidMount, componentDidUpdate, componentWillUnmount: Хук useEffect заменяет все их комбинации (включая более редкие случаи).getSnapshotBeforeUpdate, componentDidCatch и getDerivedStateFromError: В данный момент не существует хуков-аналогов для этих методов, но они будут скоро добавлены.Посмотрите небольшое демо, а затем ознакомьтесь со статьёй, которая рассказывает как делать запросы данных с помощью хуков.
\nДа! Хук useRef() может использоваться не только для DOM-рефов. Реф — это общий контейнер, а его свойство current — изменяемое и может хранить любое значение, подобно свойству экземпляра класса.
Вы можете использовать его внутри useEffect:
function Timer() {\n const intervalRef = useRef();\n useEffect(() => {\n const id = setInterval(() => {\n // ...\n });\n intervalRef.current = id; return () => {\n clearInterval(intervalRef.current);\n };\n });\n\n // ...\n}Для объявления интервала нам не понадобится реф (id может быть локальным относительно эффекта). Но это будет полезно, если потребуется сбросить интервал из обработчика события:
// ...\n function handleCancelClick() {\n clearInterval(intervalRef.current); }\n // ...В целом вы можете рассматривать рефы как свойства экземпляра класса. Старайтесь избегать установки рефов во время рендера, пока вы не реализуете ленивую инициализацию, так как это может привести к неожиданному поведению. Как правило, вы будете изменять рефы в обработчиках событий и эффектах.
\nЕсли вы привыкли писать классовые компоненты, вы скорее всего захотите вызывать useState() однократно и сразу сохранить всё состояние в одном объекте. Да, вы можете так сделать. Взгляните на пример компонента, который следует за движением курсора. Мы храним позицию и размер этого компонента в локальном состоянии.
function Box() {\n const [state, setState] = useState({ left: 0, top: 0, width: 100, height: 100 });\n // ...\n}Допустим, мы хотим написать некоторую логику, которая будет изменять значения left и top, когда пользователь двигает курсор мышки. Обратите внимание, что мы обязаны объединить эти поля с предыдущим объектом состояния вручную:
// ...\n useEffect(() => {\n function handleWindowMouseMove(e) {\n // Использование \"...state\" гарантирует, что мы не потеряем width и height setState(state => ({ ...state, left: e.pageX, top: e.pageY })); }\n // Примечание: эта реализация немного упрощена\n window.addEventListener('mousemove', handleWindowMouseMove);\n return () => window.removeEventListener('mousemove', handleWindowMouseMove);\n }, []);\n // ...Код написан так, потому что мы обновляем переменную состояния, заменяя её значение. Данное поведение отличается от this.setState, ведь этот классовый метод объединяет изменённые поля с текущим объектом состояния.
Если вам не хватает автоматического объединения состояния, вы можете написать свой хук useLegacyState, который объединяет обновления состояния объекта. Однако, вместо этого мы рекомендуем разделять состояние на несколько переменных, учитывая, какие свойства логически относятся друг к другу и будут изменяться вместе.
Например, мы можем разделить состояние нашего компонента на объекты position и size, что поможет всегда изменять только position, без необходимости волноваться об объединении:
function Box() {\n const [position, setPosition] = useState({ left: 0, top: 0 }); const [size, setSize] = useState({ width: 100, height: 100 });\n\n useEffect(() => {\n function handleWindowMouseMove(e) {\n setPosition({ left: e.pageX, top: e.pageY }); }\n // ...В разделении состояния на независимые переменные есть ещё одно преимущество. Это поможет легко вынести некоторую логику в отдельный хук в будущем, например:
\nfunction Box() {\n const position = useWindowPosition(); const [size, setSize] = useState({ width: 100, height: 100 });\n // ...\n}\n\nfunction useWindowPosition() { const [position, setPosition] = useState({ left: 0, top: 0 });\n useEffect(() => {\n // ...\n }, []);\n return position;\n}Обратите внимание, как мы смогли вынести вызов useState, изменяющий position, и соответствующих эффект в отдельный хук, практически не меняя их код. Если бы всё состояние хранилось в одном объекте, сделать это перемещение было бы на порядок сложнее.
На самом деле, оба варианта имеют право на жизнь. Однако, компоненты будут более читаемыми, если вы найдёте баланс между двумя подходами и будете группировать связанные друг с другом данные. Если работа с состоянием становится сложной, мы советуем использовать редюсер или выносить логику в отдельные хуки.
\nЭто довольно редкий случай. Вы можете использовать изменяемый реф, чтобы вручную хранить логическое значение, показывающее, прошёл ли первый рендер. В свою очередь эффект может опираться на это значение. Если вы замечаете, что эта логика нужна вам часто, вы можете вынести её в отдельный хук.
\nСейчас, вы можете сделать это вручную, используя реф:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n const prevCountRef = useRef();\n useEffect(() => {\n prevCountRef.current = count; });\n const prevCount = prevCountRef.current;\n return <h1>Сейчас: {count}, до этого: {prevCount}</h1>;\n}Это может показаться усложнённым, но вы можете вынести эту логику в отдельный хук:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n const prevCount = usePrevious(count); return <h1>Сейчас: {count}, до этого: {prevCount}</h1>;\n}\n\nfunction usePrevious(value) { const ref = useRef();\n useEffect(() => {\n ref.current = value;\n });\n return ref.current;\n}Обратите внимание, как это будет работать для пропсов, состояния или любого другого вычисляемого значения.
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n const calculation = count + 100;\n const prevCalculation = usePrevious(calculation); // ...Возможно, в будущем API React введёт хук usePrevious, так как он требуется довольно часто.
Также смотрите рекомендованный паттерн для производного состояния.
\nЛюбая функция внутри компонента, включая эффекты и обработчики событий, «видит» пропсы и состояние из функции render(), в которой она была создана. Рассмотрим такой код:
function Example() {\n const [count, setCount] = useState(0);\n\n function handleAlertClick() {\n setTimeout(() => {\n alert('Вы кликнули по: ' + count);\n }, 3000);\n }\n\n return (\n <div>\n <p>Вы кликнули {count} раз(а)</p>\n <button onClick={() => setCount(count + 1)}>\n Кликни меня\n </button>\n <button onClick={handleAlertClick}>\n Показать предупреждение\n </button>\n </div>\n );\n}Если вы сперва кликните по «Показать предупреждение», а потом увеличите счётчик, то предупреждение отобразит значение переменной count на момент нажатия по кнопке «Показать предупреждение». Такое поведение предотвращает баги в коде, который предполагает, что пропсы и состояние не меняются.
Если вы намеренно хотите считать из асинхронного колбэка свежайшее состояние, вы можете сперва сохранить его в реф, потом изменить его и затем считать его из рефа.
\nНаконец, возможна другая ситуация, почему вы видите устаревшие пропсы или состояние: когда вы используете оптимизацию с помощью «массива зависимостей», но неправильно указали какие-то зависимости. Например, если эффект передаёт вторым параметром [], но при этом использует someProp, то он продолжит «видеть» исходное значение someProp. Правильным решением является либо исправление массива, либо отказ от его использования.\nПо этим ссылкам описаны подходы к функциям в аналогичных ситуациях и другие известные способы снижения частоты вызова эффектов, исключающие передачу неправильных зависимостей.
\n\nПримечание
\nМы предоставляем правило
\nexhaustive-depsв нашем пакете линтераeslint-plugin-react-hooks. Оно предупреждает о неправильно указанных зависимостях и рекомендует их исправить.
getDerivedStateFromProps? Несмотря на то, что вам скорее всего это не нужно, в редких случаях (например, для реализации компонента <Transition>), вы можете изменять состояние прямо во время рендера. React моментально сделает повторный рендер компонента с обновлённым состоянием сразу после первого рендера, и это не будет затратно.
В этом примере, мы храним предыдущее значение пропа row в состоянии, что позволяет сравнить значения:
function ScrollView({row}) {\n const [isScrollingDown, setIsScrollingDown] = useState(false);\n const [prevRow, setPrevRow] = useState(null);\n\n if (row !== prevRow) {\n // Row изменился с прошлого рендера. Обновляем isScrollingDown.\n setIsScrollingDown(prevRow !== null && row > prevRow);\n setPrevRow(row);\n }\n\n return `Прокрутка вниз: ${isScrollingDown}`;\n}Сперва это может показаться странным, но изменение во время рендера — это именно то, чем всегда концептуально являлся метод getDerivedStateFromProps.
Оба хука useState и useReducer игнорируют обновления, если следующее значение равно предыдущему. Мутация состояния и вызов setState не приведут к повторному рендеру.
Обычно, вы не должны мутировать внутреннее состояние в React. Однако, в качестве лазейки, вы можете использовать увеличивающийся счётчик, чтобы заставить компонент повторно рендериться, если состояние не изменилось:
\n const [ignored, forceUpdate] = useReducer(x => x + 1, 0);\n\n function handleClick() {\n forceUpdate();\n }Старайтесь избегать этого подхода, если возможно.
\nНесмотря на то, что вам не понадобится это часто, вы можете предоставить некоторые императивные методы родительскому компоненту, используя хук useImperativeHandle.
Один из элементарных способов определения положения или размера DOM-узла это использование колбэк-реф. React будет вызывать этот колбэк всякий раз, когда реф привязывается к другому узлу. Вот небольшая демонстрация:
\nfunction MeasureExample() {\n const [height, setHeight] = useState(0);\n\n const measuredRef = useCallback(node => { if (node !== null) { setHeight(node.getBoundingClientRect().height); } }, []);\n return (\n <>\n <h1 ref={measuredRef}>Привет, мир</h1> <h2>Заголовок выше имеет высоту {Math.round(height)} пикселей</h2>\n </>\n );\n}Мы не выбрали useRef в этом примере, потому что объект рефа не уведомляет нас об изменениях текущего значения рефа. Использование колбэк-рефа гарантирует, что даже если дочерний компонент отображает измеренный узел позже (например, в ответ на клик), мы по-прежнему получаем уведомление об этом в родительском компоненте и можем обновлять измерения.
Обратите внимание, что мы передаём [] как массив зависимостей в useCallback. Это гарантирует, что наш колбэк-реф не изменится между повторными рендерами, а значит React не будет вызывать его без необходимости.
В данном примере колбэк-реф будет вызван только при монтировании и размонтировании компонента, хотя отрендеренный компонент <h1> остаётся на месте при последующих повторных рендерах. Если необходимо отследить изменение размера компонента, воспользуйтесь ResizeObserver или сторонним хуком, использующий этот API.
При желании вы можете извлечь эту логику в хук для повторного использования:
\nfunction MeasureExample() {\n const [rect, ref] = useClientRect(); return (\n <>\n <h1 ref={ref}>Привет, мир</h1>\n {rect !== null &&\n <h2>Заголовок выше имеет высоту {Math.round(rect.height)} пикселей</h2>\n }\n </>\n );\n}\n\nfunction useClientRect() {\n const [rect, setRect] = useState(null);\n const ref = useCallback(node => {\n if (node !== null) {\n setRect(node.getBoundingClientRect());\n }\n }, []);\n return [rect, ref];\n}const [thing, setThing] = useState()? Если вы не знакомы с этим синтаксисом, ознакомьтесь с объяснением в документации хука состояния.
\nДа. Ознакомьтесь с условным вызовом эффектов. Обратите внимание, что забыв обработать обновления, вы зачастую можете создать ошибки. Поэтому это и не является поведением по умолчанию.
\nВообще говоря, это небезопасно.
\nfunction Example({ someProp }) {\n function doSomething() {\n console.log(someProp); }\n\n useEffect(() => {\n doSomething();\n }, []); // 🔴 Так делать небезопасно (вызывать `doSomething`, который использует `someProp`)}Сложно помнить, какие пропсы и состояние используются функцией определённой вне эффекта. Именно поэтому, лучше объявлять функции нужные эффекту внутри него. Тогда легче увидеть, от каких значений из области видимости компонента зависит эффект:
\nfunction Example({ someProp }) {\n useEffect(() => {\n function doSomething() {\n console.log(someProp); }\n\n doSomething();\n }, [someProp]); // ✅ Правильно (наш эффект использует только `someProp`)}Если после такого изменения мы видим, что никакие значения из области видимости компонента не используются, то можно безопасно указать []:
useEffect(() => {\n function doSomething() {\n console.log('Привет');\n }\n\n doSomething();\n}, []); // ✅ Так можно поступить в этом примере, потому что // нет зависимости от значений из области видимости компонентаВ зависимости от ситуации, может пригодиться один из вариантов, описанных ниже.
\n\n\nПримечание
\nМы предоставляем правило
\nexhaustive-depsв пакете нашего линтераeslint-plugin-react-hooks. Оно поможет выявлять компоненты, не обрабатывающие обновления консистентно.
Давайте разберёмся, почему это важно.
\nКогда вы указываете список зависимостей через последний аргумент хуков useEffect, useLayoutEffect, useMemo, useCallback или useImperativeHandle, в него должны войти все использованные значения, которые задействованы в потоке данных React, включая пропсы, состояние и их производные.
Безопасно опускать в списке только те функции, которые не используют ни сами, ни через функции, которые они вызывают, пропсы, состояние или их производные. Так, в следующем примере показан баг:
\nfunction ProductPage({ productId }) {\n const [product, setProduct] = useState(null);\n\n async function fetchProduct() {\n const response = await fetch('http://myapi/product/' + productId); // Использует проп productId const json = await response.json();\n setProduct(json);\n }\n\n useEffect(() => {\n fetchProduct();\n }, []); // 🔴 Неправильно, потому что `fetchProduct` использует `productId` // ...\n}Рекомендовано исправлять такой код, перемещая функцию внутрь вашего эффекта. Это помогает замечать, какие пропсы и состояние используются вашим эффектом, и убедиться, что они перечислены в списке зависимостей:
\nfunction ProductPage({ productId }) {\n const [product, setProduct] = useState(null);\n\n useEffect(() => {\n // Переместив эту функцию внутрь эффекта, мы ясно видим, какие значения она использует. async function fetchProduct() { const response = await fetch('http://myapi/product/' + productId); const json = await response.json(); setProduct(json); }\n fetchProduct();\n }, [productId]); // ✅ Правильно, потому что эффект использует только productId // ...\n}Это также позволяет обрабатывать ответы, пришедшие не в порядке запросов, с помощью локальной переменной внутри эффекта:
\n useEffect(() => {\n let ignore = false; async function fetchProduct() {\n const response = await fetch('http://myapi/product/' + productId);\n const json = await response.json();\n if (!ignore) setProduct(json); }\n fetchProduct();\n return () => { ignore = true };\n }, [productId]);Мы переместили функцию внутрь эффекта, так что её не нужно указывать в списке зависимостей.
\n\n\nСовет
\nПосмотрите этот небольшой пример и эту статью, чтобы узнать больше о загрузке данных с помощью хуков.
\n
Если по какой-то причине вы не можете переместить функцию в эффект, есть другие варианты:
\nuseCallback. Тогда функция будет оставаться неизменной, до тех пор, пока не изменятся её зависимости:function ProductPage({ productId }) {\n // ✅ Оборачиваем в useCallback, чтобы избежать изменений при каждом рендере const fetchProduct = useCallback(() => { // ... Что-то делаем с productId ... }, [productId]); // ✅ Перечисляем все зависимости useCallback\n return <ProductDetails fetchProduct={fetchProduct} />;\n}\n\nfunction ProductDetails({ fetchProduct }) {\n useEffect(() => {\n fetchProduct();\n }, [fetchProduct]); // ✅ Перечисляем все зависимости useEffect // ...\n}Заметьте, что в примере выше мы всё ещё должны указать функцию в списке зависимостей. Тогда гарантируется, что изменение пропа productId у ProductPage приведёт к повторному запрашиванию данных в компоненте ProductDetails.
Бывают случаи, когда эффект может зависеть от состояния, которое очень часто изменяется. У вас может возникнуть желание не включать это состояние в список зависимостей хука, но это как правило приводит к багам:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n const id = setInterval(() => {\n setCount(count + 1); // Этот эффект зависит от переменной состояния `count` }, 1000);\n return () => clearInterval(id);\n }, []); // 🔴 Баг: `count` не указан в качестве зависимости\n return <h1>{count}</h1>;\n}Пустой набор зависимостей [] означает, что эффект будет выполняться только один раз, когда компонент монтируется, а не при каждом повторном рендере. Проблема в том, что внутри обратного вызова setInterval значение count не изменяется, потому что мы создали замыкание со значением count, установленным в 0, как это было при выполнении обратного вызова эффекта. Каждую секунду этот обратный вызов вызывает setCount(0 + 1), поэтому счетчик никогда не превышает 1.
Если переписать список зависимостей как [count], то баг будет устранён, но это приведёт к сбрасыванию интервала при каждом изменении. Такое поведение может быть нежелательно. Чтобы исправить это, мы можем применить форму функционального обновления хука setState, которая позволяет указать, как должно меняться состояние, не ссылаясь явно на текущее состояние:
function Counter() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n const id = setInterval(() => {\n setCount(c => c + 1); // ✅ Эта строчка не зависит от внешней переменной `count` }, 1000);\n return () => clearInterval(id);\n }, []); // ✅ Наш эффект не использует никаких переменных из области видимости компонента\n return <h1>{count}</h1>;\n}(Идентичность функции setCount гарантирована, поэтому её можно безопасно не включать в список зависимостей.)
Теперь обратный вызов setInterval выполняется один раз в секунду, но каждый раз, когда внутренний вызов setCount может использовать обновленное значение для count (называемое c в обратном вызове здесь.)
В более сложных случаях (например, когда одно состояние зависит от другого), попробуйте перенести логику обновления состояния из хука эффекта в хук useReducer. Эта статья иллюстрирует пример того, как это сделать. Идентичность функции dispatch из хука useReducer всегда стабильна — даже если функция редюсера объявлена внутри компонента и считывает его пропсы.
В крайнем случае если вы хотите реализовать что-то наподобие this в классах, вы можете использовать реф, чтобы хранить в нём изменяемую переменную. Тогда можно писать и читать из него. Например:
function Example(props) {\n // Сохраняем свежайшие значения пропсов в ref const latestProps = useRef(props); useEffect(() => { latestProps.current = props; });\n useEffect(() => {\n function tick() {\n // Считываем свежайшие значения пропсов в любое время console.log(latestProps.current); }\n\n const id = setInterval(tick, 1000);\n return () => clearInterval(id);\n }, []); // Этот эффект никогда не исполняется повторно}Рекомендуется прибегать к этому подходу только если не удалось найти лучшей альтернативы, поскольку компоненты, полагающиеся на изменчивость, менее предсказуемы. Если какой-то конкретный паттерн плохо получается выразить, откройте ишью на GitHub с примером исполняемого кода и мы постараемся помочь.
\nshouldComponentUpdate? Вы можете обернуть функциональный компонент в вызов React.memo для поверхностного сравнения его пропсов:
const Button = React.memo((props) => {\n // ваш компонент\n});Это функция не является хуком, так как она не ведёт себя как хук. React.memo аналогична PureComponent, но она сравнивает только пропсы. (Вы также можете добавить второй аргумент, чтобы определить свою функцию сравнения, которая примет старые и новые пропсы. Если эта функция вернёт true, обновление будет пропущено.)
React.memo не сравнивает состояние, потому что не существует единого объекта, который можно сравнить. Но вы можете также сделать дочерние компоненты чистыми или даже оптимизировать определённые дочерние компоненты, используя хук useMemo.
Хук useMemo позволяет вам закешировать вычисления между несколькими рендерами, путём запоминания прошлого результата:
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);Этот код вызовет computeExpensiveValue(a, b). Но если зависимости [a, b] не изменились с прошлого рендера, useMemo пропустит повторный вызов и повторно использует значения, которые он вернул в прошлый раз.
Помните, что функция, передаваемая в useMemo, выполняется во время рендера. Не стоит делать в ней что-то, что вы обычно не делаете во время рендера. Например, побочные эффекты выполняются в хуке useEffect, а не в useMemo.
Рассматриваете useMemo, как оптимизацию производительности, но не стоит полагаться на неё на 100%. В будущем React сможет забыть прошлые закешированные значения и провести перерасчёт на следующем рендере, например, для освобождения памяти, занятой компонентами вне экрана. Пишите ваш код так, чтобы он мог работать без useMemo, и только тогда добавляйте оптимизацию производительности. (Для редких случаев, когда значение не должно никогда пересчитываться, вы можете лениво инициализировать реф.)
Также удобно, что useMemo позволяет пропускать затратные повторные рендеры дочерних компонентов:
function Parent({ a, b }) {\n // Рендерится повторно, только если `a` изменится:\n const child1 = useMemo(() => <Child1 a={a} />, [a]);\n // Рендерится повторно, только если `b` изменится:\n const child2 = useMemo(() => <Child2 b={b} />, [b]);\n return (\n <>\n {child1}\n {child2}\n </>\n )\n}Обратите внимание, что этот подход не будет работать внутри циклов, так как вызовы хуков не могут быть помещены внутрь циклов. Но вы можете создать отдельный компонент для элемента списка, и вызвать useMemo там.
Хук useMemo позволяет вам закешировать ресурсозатратные вычисления, если зависимости не изменились. Однако, этот способ не гарантирует, что повторных вычислений не случится. Иногда вам нужно удостовериться, что объект будет создан только один раз.
Первый частый вариант использования — создание изначального состояния затратно:
\nfunction Table(props) {\n // ⚠️ createRows() вызывается на каждом рендере\n const [rows, setRows] = useState(createRows(props.count));\n // ...\n}Чтобы повторно не создавать начальное состояние (которое по факту игнорируется), мы можем передать функцию в useState:
function Table(props) {\n // ✅ createRows() будет вызван только один раз\n const [rows, setRows] = useState(() => createRows(props.count));\n // ...\n}React вызовет эту функцию один раз во время первого рендера. Смотрите справочник API по хуку useState.
Иногда, вы захотите избежать повторных вызовов хука useRef(). Например, возможно вы захотите убедиться, что экземпляр некоторого императивного класса создаётся только один раз:
function Image(props) {\n // ⚠️ IntersectionObserver создаётся на каждом рендере\n const ref = useRef(new IntersectionObserver(onIntersect));\n // ...\n}У хука useRef нет реализации, принимающей специальную функцию, как у useState. Вместо этого, вы можете написать свою функцию, которая будет лениво создавать и назначать этот экземпляр:
function Image(props) {\n const ref = useRef(null);\n\n // ✅ IntersectionObserver лениво создаётся только один раз\n function getObserver() {\n if (ref.current === null) {\n ref.current = new IntersectionObserver(onIntersect);\n }\n return ref.current;\n }\n\n // Когда он вам понадобится, вызовите getObserver()\n // ...\n}Этот подход позволяет избежать создания больших объектов на всех этапах, кроме первого рендера, когда это действительно необходимо. Если вы используете Flow или TypeScript, вы можете также установить для getObserver() непустой тип для уверенности.
Нет. В современных браузерах сырая производительность замыканий не сильно отличается от классов, кроме особых случаев.
\nТакже учитывайте, что реализация хуков более эффективна по нескольким причинам:
\nТрадиционно, проблемы с оптимизацией встроенных функций в React связаны с тем, как передача новых колбэков на каждом рендере ломает оптимизации shouldComponentUpdate в дочерних компонентах. Подход с хуками может решить эту проблему тремя способами.
Хук useCallback позволяет сохранять ту же самую ссылку на колбэк между повторными рендерами, поэтому shouldComponentUpdate продолжит корректную работу:
// Не создастся заново, пока `a` или `b` не изменятся\nconst memoizedCallback = useCallback(() => { doSomething(a, b);\n}, [a, b]);useMemo облегчает контроль, когда конкретный дочерний компонент должен обновляться, уменьшая нужду в использовании чистых компонентов.useReducer уменьшает необходимость передавать колбэки глубоко вниз по дереву, как описано ниже.Мы поняли, что большинству разработчиков не нравится вручную передавать колбэки вниз на каждом уровне дерева компонентов. Даже учитывая, что этот подход более явный, это может показаться чересчур громоздким.
\nВ качестве альтернативы для больших деревьев компонентов мы рекомендуем передавать вниз функцию dispatch из хука useReducer через контекст:
const TodosDispatch = React.createContext(null);\n\nfunction TodosApp() {\n // Примечание: `dispatch` не изменится во время повторных рендеров const [todos, dispatch] = useReducer(todosReducer);\n return (\n <TodosDispatch.Provider value={dispatch}>\n <DeepTree todos={todos} />\n </TodosDispatch.Provider>\n );\n}Любой дочерний компонент в дереве внутри TodosApp может использовать функцию dispatch, чтобы передать объекты-действия в TodosApp:
function DeepChild(props) {\n // Если мы хотим выполнить действие, мы можем получить dispatch из контекста. const dispatch = useContext(TodosDispatch);\n function handleClick() {\n dispatch({ type: 'add', text: 'Привет' });\n }\n\n return (\n <button onClick={handleClick}>Добавить задание</button>\n );\n}Этот вариант более удобен как с точки зрения поддержки кода (не нужно добавлять пропсы для новых колбэков), так и в разрезе избежания общих проблем с колбэками. Передача функции dispatch по такому принципу — это рекомендуемый подход для вызова колбэков и избежания нежелательных обновлений в глубине дерева компонентов.
Обратите внимание, что вы также можете передавать состояние приложения вниз через пропсы (более явно) или через контекст (более удобно для глубокого дерева). Если ваш контекст в том числе передаёт некое состояние, используйте два разных типа контекста. Так как контекст dispatch никогда не изменяется, то компоненты, использующие его, не будут нуждаться в повторном рендере, если только им не требуется ещё и контекст с состоянием приложения.
useCallback? \n\nПримечание
\nМы рекомендуем передавать
\ndispatchвниз через контекст вместо передачи отдельных колбэков через пропсы. Следующий подход приведён тут только для полноты картины в качестве лазейки.Также обратите внимание, что этот подход может вызвать проблемы в параллельном режиме. Мы планируем предоставить более удобные альтернативы в будущем, но самый безопасный вариант сейчас — всегда отменять колбэк, если значение, на которое он опирается, поменялось.
\n
В некоторых редких случаях, вам может понадобиться закешировать колбэк с помощью хука useCallback, но кеширование не будет работать хорошо, потому что внутренняя функция будет пересоздаваться слишком часто. Если функция, которую вы кешируете, является обработчиком событий и не используется во время рендера, вы можете использовать реф в качестве свойства экземпляра, и вручную сохранить туда последнее значение:
function Form() {\n const [text, updateText] = useState('');\n const textRef = useRef();\n\n useEffect(() => {\n textRef.current = text; // Записать это в реф });\n\n const handleSubmit = useCallback(() => {\n const currentText = textRef.current; // Прочитать из рефа alert(currentText);\n }, [textRef]); // Избегаем повторных созданий handleSubmit\n\n return (\n <>\n <input value={text} onChange={e => updateText(e.target.value)} />\n <ExpensiveTree onSubmit={handleSubmit} />\n </>\n );\n}Это довольно запутанный подход, но он показывает, что вы можете сделать эту хитрую оптимизацию, если это вам действительно необходимо. В любом случае, советуем вынести эту логику в отдельный хук:
\nfunction Form() {\n const [text, updateText] = useState('');\n // Будет закешировано, даже если значение `text` изменится:\n const handleSubmit = useEventCallback(() => { alert(text);\n }, [text]);\n\n return (\n <>\n <input value={text} onChange={e => updateText(e.target.value)} />\n <ExpensiveTree onSubmit={handleSubmit} />\n </>\n );\n}\n\nfunction useEventCallback(fn, dependencies) { const ref = useRef(() => {\n throw new Error('Невозможно вызвать обработчик события во время рендера.');\n });\n\n useEffect(() => {\n ref.current = fn;\n }, [fn, ...dependencies]);\n\n return useCallback(() => {\n const fn = ref.current;\n return fn();\n }, [ref]);\n}В любом случае мы не советуем использовать этот подход и показываем его тут только для полноты картины. Вместо этого, старайтесь избегать передачи колбэков глубоко вниз в дерево.
\nReact следит за тем, какой компонент рендерится в данный момент. Благодаря правилам хуков, мы знаем, что хуки вызываются только из React-компонентов (пользовательские хуки также вызываются только из React-компонентов).
\nСуществует внутренний список ячеек памяти, связанных с каждым компонентом. Они являются JavaScript-объектами, в которых мы можем хранить некоторые данные. Когда вызывается некий хук, например useState(), он читает значение текущей ячейки (или инициализирует её во время первого рендера) и двигает указатель на следующую. Таким способом каждый вызов useState() получит своё независимое состояние.
Хуки были основаны на следующих идеях и экспериментах:
\nadopt, в качестве синтаксического сахара для паттерна рендер-пропс.Себастьян Маркбаге (Sebastian Markbåge) предложил изначальный дизайн хуков, который позднее улучшили Эндрю Кларк (Andrew Clark), Софи Алперт (Sophie Alpert), Доминик Ганнауэй (Dominic Gannaway) и другие участники команды React.
","frontmatter":{"title":"Хуки: ответы на вопросы","next":null,"prev":"hooks-reference.html"},"fields":{"path":"content/docs/hooks-faq.md","slug":"docs/hooks-faq.html"}}},"pageContext":{"slug":"docs/hooks-faq.html"}},"staticQueryHashes":[]}