Хуки — це новинка в React 16.8. Вони дозволяють вам використовувати стан та інші можливості React без написання класу.
\nНа цій сторінці ви знайдете відповіді на деякі поширені питання щодо хуків.
\n\nПочинаючи з версії 16.8.0, React включає стабільну реалізацію хуків для:
\nЗверніть увагу на те, що всі пакунки React мають бути версії 16.8.0 або вище, щоб підтримувати хуки. Хуки не будуть працювати, якщо ви забудете оновити, наприклад, React DOM.
\nReact Native 0.59 версії 0.59 та вище підтримує хуки.
\nНі. Ми не плануємо видаляти класи з React — нам потрібно поставляти програмні продукти і ми не можемо дозволити собі переписувати кодову базу. Ми рекомендуємо спробувати хуки у новому коді.
\nХуки пропонують новий, потужний і виразний шлях для повторного використання функціональності між компонентами. “Створення користувацьких хуків” надає уявлення того, що ви можете реалізувати. Ця стаття, написана членом основної команди розробників React, детально розповідає про нові можливості, які відкривають хуки.
\nХуки — це більш прямий спосіб використання особливостей React про які ви вже знаєте: стан, життєвий цикл, контекст і рефи. Хуки не змінюють основні принципи роботи React і ваші знання компонентів, пропсів та низхідного потоку даних залишаться актуальними.
\nХуки самі по собі мають криву вивчення. Якщо у цій документації чогось не вистачає, підніміть питання і ми спробуємо допомогти вам.
\nКоли ви будете готові, ми заохочуємо вас почати використовувати хуки у ваших нових компонентах. Впевніться, що кожен член вашої команди підтримує їх використання і ознайомлений з документацією. Ми не рекомендуємо переписувати існуючі класи з використанням хуків, якщо ви не плануєте їх переписувати у будь-якому випадку (наприклад, щоб виправити помилку).
\nВи не можете використовувати хуки всередині класового компонента, але ви безумовно можете комбінувати класи і функціональні компоненти з хуками в одному дереві. Чи є компонент класом, чи функцією — неважливо, оскільки це лише деталь реалізації цього компонента. Ми очікуємо, що в майбутньому хуки будуть основним методом написання React-компонентів.
\nНашою метою є покриття всіх можливостей класів хуками якнайшвидше. Наразі немає альтернативи у вигляді хуків для таких рідковживаних методів життєвого циклу як getSnapshotBeforeUpdate, getDerivedStateFromError та componentDidCatch, але ми плануємо скоро їх додати.
Оскільки хуки з’явились зовсім нещодавно, то не всі сторонні бібліотеки можуть бути сумісними з ними.
\nЧасто рендер пропси та компоненти вищого порядку рендерять лише одного нащадка. Ми вважаємо, що хуки є простішим шляхом для того, щоб зробити це. Все ще ми можемо використовувати обидва шаблони (наприклад, віртуальний компонент скролінгу може мати проп renderItem чи візуальний контейнер може мати власну структуру DOM). Але у більшості випадків, хуків буде достатньо для зменшення кількості вкладень у ващому дереві.
Ви можете використовувати ті ж самі API, що і завжди — вони продовжують працювати.
\nReact Redux, починаючи від версії 7.1.0, підтримує API хуків і представляє хуки useDispatch та useSelector.
React Router підтримує хуки, починаючи від версії 5.1.
\nІнші бібліотеки можливо будуть підтримувати хуки у майбутньому.
\nХуки були спроектовані з урахуванням статичної типізації. Оскільки вони є функціями, то їх легше правильно типізувати, аніж, скажімо, компоненти вищого порядку. Найновіші версії Flow і TypeScript для React вже включають підтримку хуків.
\nНе менш важливо і те, що користувацькі хуки надають вам можливість накласти обмеження на React API, якщо вам потрібно типізувати їх більш строго певним чином. 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Ми надаємо плагін для ESLint, котрий змушує дотримуватись правил хуків для уникнення помилок. Він припускає, що кожна функція, яка починається з ”use” і великої літери після нього, є хуком. Ми розуміємо, що це припущення не ідеальне і може привести до хибних спрацювань, але без подібної домовленості на рівні екосистеми просто неможливо змусити хуки працювати коректно, а довші імена можуть завадити людям впроваджувати хуки або ж дотримуватись домовленості.
У деталях правила вимагають, щоб:
\nPascalCase-функції (тобто компонента) чи іншої useSomething функції (тобто користувацького хука).Існує ще кілька правил, що можуть змінитись відповідно до того, як ми змінюємо правила для балансування між пошуком помилок і уникненням хибних спрацювань.
\nconstructor: Функціональні компоненти не потребують конструктора. Ви можете ініціалізувати стан при виклику useState. Якщо обчислення початкового стану є вартісною операцію, можна передати функцію до useState.getDerivedStateFromProps: Натомість заплануйте оновлення при рендерингу.shouldComponentUpdate: Зверніть увагу на React.memo нижче.render: Це тіло функціонального компонента.componentDidMount, componentDidUpdate, componentWillUnmount: Хук useEffect може замінити всі їхні комбінації (включно з менш частими випадками).getSnapshotBeforeUpdate, componentDidCatch і getDerivedStateFromError: Поки що немає хуків, еквівалентних цим методам, але вони будуть додані найближчим часом.Ось невелике демо, що допоможе вам розпочати. Щоб дізнатися більше, ознайомтесь з цією статтею про вибірку даних з допомогою хуків.
\nТак! Хук useRef() може використовуватись не лише для рефів DOM. Об’єкт “ref” є загальним контейнером, властивість 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 and 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 і відповідний ефект у користувацький хук без зміни їхнього коду. Якби весь стан був одним об’єктом, то зробити це було б значно складніше.
Чи зерігаєте ви весь стан з використанням одного виклику useState, чи викликаєте useState для кожного поля окремо — обидва підходи будуть працювати. Але компоненти буде легше читати, якщо ви знайдете баланс між підходами і будете групувати пов’язані між собою змінні стану. Якщо логіка стану стає складною, ми радимо керувати нею з допомогою редюсера чи користувацького хука.
Це доволі нечастий випадок. Якщо вам це потрібно, ви можете використати змінний реф, щоб вручну зберегти логічне значення, що вказує на те чи відбувся, а потім перевірити його значення у вашому ефекті. (Якщо вам потрібно робити це часто, можете створити для цього користувацький хук.)
\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); // ...Цілком можливо, що у майбутньому у React буде реалізовано хук usePrevious, оскільки це потрібно відносно часто.
Також дивіться рекомендований шаблон для похідного стану.
\nКожна функція в компоненті, включно з обробниками подій та ефектами, “бачить” значення пропсів та стану того рендеру, під час якого вони були створені. Наприклад, розглянемо такий код:
\nfunction 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}Якщо ви спочатку натиснента “Показати попередженняt”, а потім інкрементуєте лічильник, попередження покаже значення змінної count на момент натискання кнопки “Показати попередження”. Це виключає помилки в коді, що припускає незмінність стану чи пропсів.
Якщо ви навмисно хочете зчитати найновіший стан з деякої асинхронної функції зворотнього виклику, ви можете зберегти його в рефі, змінити його і прочитати його значення.
\nОкрім цього, іншою можливою причиною того, що ви бачите застарілі пропси чи стан можуть бути неправильно вказані значення залежностей при використанні оптимізації за допомогою “масиву залежностей”. Наприклад, в ефекті другим аргументом вказано значення [], але при цьому він зчитує значення someProp, він продовжить “бачити” початкове значення someProp. Рішенням може бути вказання правильного масиву залежностей або відмова від нього взагалі. Ось тут можна дізнатись як вести себе з функціями, а тут інші відомі способи зниження частоти запуску ефектів без пропускання передачі залежностей.
\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}>Hello, world</h1> <h2>Заголовок вище має висоту {Math.round(height)} пікселів</h2>\n </>\n );\n}У цьому прикладі ми не використали useRef, оскільки об’єкт рефу не повідомляє нас про зміни поточного значення рефу. Використання рефу зворотнього виклику гарантує, що навіть якщо дочірній компонент відображає обмежений вузол пізніше (наприклад, у відповідь на натискання), ми все рівно отримаємо повідомлення про це у батьківському компоненті і зможемо оновити обмеження.
Зверніть увагу на передачу [] у якості масива залежностей useCallback. Вона гарантує, що наш реф зворотнього виклику не зміниться між повторними рендерами, а отже React не буде викликати його без необхідності.
Також, реф зворотнього виклику буде викликано лише коли компоненту монтується та демонтується, так як відрендерений <h1> компонент залишається присутнім протягом всіх ререндерів. Якщо ви хочете отримувати повідомлення, коли компонент змінює розмір, ви можете скористатися ResizeObserver або користувацьким хуком.
За бажанням можна виокремити цю логіку у повторно використовуваний хук:
\nfunction MeasureExample() {\n const [rect, ref] = useClientRect(); return (\n <>\n <h1 ref={ref}>Hello, world</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}Якщо ви не знайомі з цим синтаксисом, прочитайте пояснення у документації для хука стану.
\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]); // ✅ OK (наш ефект використовує лише `someProp`)}Якщо після подібної зміни ми не використовуємо жодних значень з області видимості компонента, то ми можемо безпечно вказати []:
useEffect(() => {\n function doSomething() {\n console.log('hello');\n }\n\n doSomething();\n}, []); // ✅ OK у цьому прикладі, тому що ми не використовуємо *жодних* значень з області видимості компонентаЗалежно від ваших потреб є ще кілька варіантів, описаних нижче.
\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\n fetchProduct();\n return () => { ignore = true }; }, [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 // ...\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, як це було при запуску ефекту callback. Кожну секунду ця функція зворотнього виклику потім викликає setCount (0 + 1), тому кількість ніколи не перевищує 1.
Вказання [count] у якості списка залежностей виправить помилку, але спричинить скидання інтервалу на кожному оновленні. Фактично, кожен setInterval отримав би шанс бути виконаним перед очищенням (подібно до setTimeout.) Така поведінка може бути небажаною. Щоб виправити це, ми можемо використати функціональну форму оновлення 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 // Зберегти останні пропси у рефі. 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 }, []); // Цей ефект ніколи не буде запущено повторно}Робіть так лише якщо ви не можете знайти кращої альтернативи, тому що поведінка компонентів, яка покладається на змінність, є менш передбачуваною. Якщо існує якийсь шаблон, який ви не можете гарно виразити, відкрийте проблему з прикладом виконуваного коду і ми постараємося вам допомогти.
\nВи можете обгорнути функціональний компонент у виклик 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 як на оптимізацію продуктивності, а не на семантичу гарантію. У майбутньому 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 дозволяє запам’ятати вартісне обчислення для однакових залежностей. Проте він відіграє лише роль підказки для React і не гарантує, що повторні обчислення не будуть виконані знову. Але часом ви маєте бути впевнені, що об’єкт був створений лише раз.
Першим поширеним випадком є вартісне створення початкового стану:
\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 ніколи не змінюється, а отже компоненти, що зчитують його, не потребують повторного рендеру, якщо тільки вони не потребують контекст зі станом додатку.
\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 повторно, як би було у випадку з [text]\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, як синтаксичного цукру для рендер пропсів, запропонована Домініком Ґенневеєм (Dominic Gannaway).Себастьян Маркбоге (Sebastian Markbåge) запропонував початковий дизайн хуків, який удосконалили Ендрю Кларк (Andrew Clark), Софі Алперт (Sophie Alpert), Домінік Ґенневей (Dominic Gannaway) та інші члени команди React.
","frontmatter":{"title":"Хуки: FAQ","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":[]}