Хуки useTransition и useDeferredValue в ReactJS 18
2 года назад·3 мин. на чтение
В React 18, релиз которого произошел в марте 2022, появилось много новых инструментов для написания производительных и отзывчивых приложений. Одним из заметных изменений является механизм рендеринга с новой ключевой концепцией: конкурентный рендеринг (concurrent rendering).
В этой статье повнимательнее рассмотрим два новых хука:
Какое обновление можно считать срочным, а какое обычным?
Хук
До React 18 все обновления состояния помечались как "срочные". Это означает, что все обновления состояния обрабатывались одинаково с одинаковым приоритетом.
С помощью
Когда использовать
Одним из примеров может быть список товаров с параметрами фильтрации.
Когда вы переключаете чекбоксы, чтобы выбрать размер или цвет одежды, вы ожидаете, что чекбоксы сразу же отобразят отмеченное или снятое состояние.
А сам список товаров, которые необходимо обновить согласно фильтрам, может быть отдельным и менее срочным обновлением.
Как использовать
Хук
Когда использовать
С помощью
Как использовать
useTransition()
и useDeferredValue()
.
Эти два хука дают возможность определять приоритет обновления состояния, или, скорее, указывать, является ли обновление менее важным, чем другие, и откладывать его в пользу более срочных.
- Срочные обновления: отражают прямое взаимодействие, такое как набор текста, клики, нажатия и т. д., т.е. то с чем взаимодействует пользователь. Когда вы вводите текст в поле ввода, вы хотите сразу увидеть введенный вами текст. В противном случае UI будет казаться медленным и подлагивать. Поэтому мы хотим сделать такие обновления приоритетным.
- Обычные обновления: переход пользовательского интерфейса из одного вида в другой. Пользователи знают, что представление должно измениться или обновиться (например, когда ожидается ответ на запрос данных). Даже если есть небольшая задержка, это можно рассматривать как ожидаемое поведение, и это не будет восприниматься как медлительность приложения.
Хук useTransition()
и функция startTransition()
До React 18 все обновления состояния помечались как "срочные". Это означает, что все обновления состояния обрабатывались одинаково с одинаковым приоритетом.
С помощью useTransition()
теперь можно пометить некоторые обновления состояния как несрочные.
Когда использовать useTransition()
?
Одним из примеров может быть список товаров с параметрами фильтрации.
Когда вы переключаете чекбоксы, чтобы выбрать размер или цвет одежды, вы ожидаете, что чекбоксы сразу же отобразят отмеченное или снятое состояние.
А сам список товаров, которые необходимо обновить согласно фильтрам, может быть отдельным и менее срочным обновлением.
Как использовать useTransition()
?
function App() { const [isPending, startTransition] = useTransition(); const [searchQuery, setSearchQuery] = useState(''); // запрос данных, который занимает некоторое время const filteredResults = getProducts(searchQuery); function handleQueryChange(event) { startTransition(() => { // оборачивая setSearchQuery() в startTransition(), // мы помечаем эти обновления как менее важные setSearchQuery(event.target.value); }); } return ( <div> <input type="text" onChange={handleQueryChange} /> {isPending && <span>Loading...</span>} <ProductsList results={filteredResults} /> </div> ); }
Хук useDeferredValue()
useDeferredValue()
очень похож на useTransition()
в том, что он позволяет отложить несрочное обновление состояния, но применяется его к части дерева.
Это похоже методы debounce и throttle, которые мы часто используем для отложенных обновлений. React будет работать с такими обновлениями, как только завершатся срочные обновления.
Когда использовать useDeferredValue()
?
С помощью useTransition()
вы сами решаете, когда конкретное обновление состояния может быть помечено как менее срочное. Но иногда такой возможности может и не быть, например, если фрагмент кода находится в сторонней библиотеке.
В таких случаях можно воспользоваться хуком useDeferredValue()
. С помощью useDeferredValue()
вы можете обернуть значение и пометить его изменения как менее важные и, следовательно, отложить повторный рендеринг.
useDeferredValue()
будет возвращать предыдущее значение до тех пор, пока есть более срочные обновления для завершения и отображения дерева с обновленным значением.
Как использовать useDeferredValue()
?
function ProductsList({ results }) { // deferredResults получат обновленные данные // когда завершатся срочные обновления const deferredResults = useDeferredValue(results); return ( <ul> {deferredResults.map((product) => ( <li key={product.id}>{product.title}</li> ))} </ul> ); }
Итоги
Эти два новых хука позволяют сделать интерфейсы максимально отзывчивыми, даже в сложных приложениях с большим количеством повторных рендерингов, отдавая приоритет обновлениям, которые имеют решающее значение для взаимодействия с пользователем, и помечая некоторые другие как менее важные. Это не означает, что нужно оборачивать все состояния этими хуками. Их следует использовать в крайнем случае, если приложение или компоненты не могут быть оптимизированы другими способами (например, при помощи lazy loading’а, пагинации, веб-воркеров и т. д.).Что за хук useId в React?
2 года назад·1 мин. на чтение
useId - хук, который появился в React 18. Он помогает при работе с уникальными идентификаторами в компонентах.
Как работает хук useId
?
Основным вариантом использования useId
является создание уникальных идентификаторов для использования в элементах HTML. Лучшим примером этого может быть создание идентификатора для input и label, которые указывают на тот же идентификатор. Например, если у вас есть компонент EmailForm
, вы можете написать его так.
function EmailForm() { return ( <> <label htmlFor="email">Email</label> <input id="email" type="email" /> </> ) }
email
. Это, очевидно, плохо, поскольку каждый идентификатор на странице должен быть уникальным, и, кроме того, ваши label при нажатии теперь будут фокусироваться на первом инпуте с email
на странице, а не на инпуте электронной почты, связанном с этим label. Чтобы исправить это, мы можем использовать useId
.
Хукfunction EmailForm() { const id = useId() return ( <> <label htmlFor={id}>Email</label> <input id={id} type="email" /> </> ) }
useId
— это простой хук, который не принимает входных данных и возвращает уникальный идентификатор. Этот идентификатор уникален для каждого отдельного компонента, что означает, что мы можем отображать эту форму на нашей странице столько раз, сколько захотим, не беспокоясь о повторяющихся идентификаторах.
Идентификаторы, сгенерированные useId
, будут выглядеть примерно так: :r1:
, :r2:
и т.д.
Получение элементов с querySelector
Одна вещь, которую следует отметить в отношении хука useId
, заключается в том, что идентификаторы, созданные им, являются недопустимыми селекторами для использования с методом querySelector
. Это сделано намеренно, поскольку React не хочет, чтобы вы выбирали элементы по их идентификатору, используя что-то вроде querySelector
. Вместо этого вы должны использовать для этого хук useRef
. Если вы не знакомы с хуком useRef
, вам следует ознакомиться с руководством по хуку useRef
.
Использование нескольких идентификаторов в одном компоненте
Одна важная вещь, которую следует отметить в отношении этого хука, заключается в том, что вы должны использовать его только один раз для каждого компонента. Это поможет с производительностью и по-прежнему даст вам преимущества, которые вы хотите получить от хука.Как вы можете видеть в приведенном выше примере, мы использовалиfunction LogInForm() { const id = useId() return ( <> <div> <label htmlFor={`${id}-email`}>Email</label> <input id={`${id}-email`} type="email" /> </div> <div> <label htmlFor={`${id}-password`}>Password</label> <input id={`${id}-password`} type="password" /> </div> </> ) }
useId
один раз в компоненте и просто добавили уникальный идентификатор в конец идентификатора, сгенерированного useId
. Это по-прежнему дает нам уникальные идентификаторы для всех элементов на нашей странице, но избавляет нас от накладных расходов на производительность, связанных с многократным вызовом этого хука в компоненте с несколькими идентификаторами.
Рендеринг на стороне сервера
Еще одна важная причина использовать этот хук — помочь с рендерингом на стороне сервера. Если вы используете что-то вродеMath.random()
или другой генератор случайных чисел для генерации идентификаторов, вы столкнетесь с проблемой, когда ваши идентификаторы для одного и того же компонента на сервере отличаются от идентификаторов для этих компонентов на клиенте. Это становится особенно проблематичным, когда в вашем приложении есть сочетание клиентского и серверного отображаемого кода, поскольку теперь вы больше не можете доверять идентификаторам, сгенерированным вашим кодом.
Хук useId
исправляет все это, поскольку сгенерированные им идентификаторы не являются случайными. Это означает, что идентификатор будет совпадать между сервером и клиентом, и независимо от того, какое сочетание клиент-серверный код у вас есть, вы можете быть уверены, что ваши идентификаторы верны. Это самая большая причина для использования этого хука, поскольку он значительно упрощает работу с серверным кодом.
Итоги
Легко упустить из виду хукuseId
в React 18 из-за всех других удивительных функций/хуков, выпущенных вместе с ним, но этот маленький хук невероятно полезен.