Как начинать проект на React в 2024 году

В своем блоге Робин Вирух сделал ежегодный обзор как начинать новый проект на React в 2024 году. Вот его предложения:

- React и Vite. Если вы раньше использовали Create React App, то сейчас лучше перейти на Vite. Он быстрее, более активно поддерживается и схож с CRA. В нем также нет какого-то фреймворка, на основе которого строится приложение.

- Next.js или Remix. Если нужен готовый фреймворк с SSR/SSG. Под капотом много готовых решений для облегчения разработки, и можно легко добиться высоких показателей производительности, если все правильно делать.

- Astro. Фреймворк для создания MPA сайтов. Этот случай подходит, если делаете сайт с упором на контент: блог, портфолио, лендинги. Ориентирован на рендер на сервере и по умолчанию не поставляет JS в браузер.

https://www.robinwieruch.de/react-starter/

Мысли про Remix

Возможности React растут, а технические подходы к созданию UI стали более сложными, появляются новые «мета-фреймворки», которые позволяют быстрее создавать более производительные и масштабируемые приложения, прилагая меньшие усилия к разработке. На данный момент есть два популярных «мета-фреймворка» – Next.js и Remix.

Соломон Хоук поделился своими мыслями про Remix. Что нравится в Remix:

- Хорошая документация, в которой легко ориентироваться, есть гайды и темам и справочник API.

- Изучение Remix связано с пониманием роутинга, загрузкой данных и изучением соглашений, принятых в Remix: наименование файла, название экспортируемых функций и констант.

- В Remix уделяется внимание стандартам веб API, например используется Response и FormData.

- Для большинства рабочих кейсов не надо устанавливать стейт-менеджер и библиотеку для получения данных (типа react-query). Хватает встроенного API, например loader для получения данных.

Также автор описал вещи, которые не нравятся в Remix:

- Remix использует esbuild, но не дает доступа к его конфигурации.

- Получение данных связано с роутом через loader. Это может стать проблемой, если хотите получать данные на уровне компонента. Как вариант, использовать react-query.

- Проблема с ESM модулями. Remix бандлит сервер в формате CommonJS и по умолчанию не бандлит зависимые модули.

https://www.viget.com/articles/thoughts-on-remix/

Улучшаем типизацию роутинга в Next.js

В Next.js есть экспериментальная фича для генерации типов роутов:

const nextConfig = {
  experimental: {
    typedRoutes: true,
  },
}

Однако, этот способ не всегда применим, он позволяет только проверить правильность написания пути роута в href у Link:

// Валидно
<Link href="/about" />
 
// Ошибка
<Link href="/aboot" />

У typedRoutes есть несколько ограничений:

- нет валидации типа query params и проверок в runtime.
- нет подсказок для динамических роутов.
- нет валидации типа при передаче href как объекта <Link href={{href: '/about', query: {ref: 'hello'}}} />
- нет валидации типа для useParams() и useSearchParams()

Чтобы обеспечить валидацию типа и проверок в runtime, автор статьи предлагает использовать Zod и создал утилитарную функцию makeRoute. Пример как используется makeRoute:

Динамические роуты:

export const OrgParams = z.object({orgId: z.string()})

export const Routes = {
  home: makeRoute(({orgId}) => `/org/${orgId}`, OrgParams)
}
…
<Link href={Routes.home({orgId: 'g4eion3e3'})} />

useParams с типизацией:

// type = {orgId: string}
const params = Routes.home.useParams()

Query параметры:

export const SignupSearchParams = z.object({
  invitationId: z.string().optional().nullable(),
})

export const Routes = {
    signup: makeRoute(() => "/signup", z.object({}), SignupSearchParams),
}
…
<Link href={Routes.signup({}, {search: {invitationId: '8haf3dx'}})} />

https://www.flightcontrol.dev/blog/fix-nextjs-routing-to-have-full-type-safety

Использование Intersection Observer в React

react-intersection-observer – библиотека для использования Intersection Observer в React. Можно использовать через хук useInView и через компонент InView:

const Component = () => {
  const { ref, inView, entry } = useInView({
    /* Optional options */
    threshold: 0,
  });

  return (
    <div ref={ref}>
      <h2>{`Header inside viewport ${inView}.`}</h2>
    </div>
  );
};

Поддерживаются параметры Intersection Observer v2: trackVisibility и delay.

В репозитории есть рецепты готовых сценариев использования: ленивая загрузка изображений, триггер анимации и отслеживание показов.

https://github.com/thebuilder/react-intersection-observer

Релиз Storybook 8 Beta

Вышел релиз Storybook 8 Beta. Какие он принес изменения:

- Значительное улучшение производительности. Поменяли компилятор, вместо Babel теперь SWC. Для проектов на React автоматически генерируются контролы с помощью react-docgen, это ускорило время запуска на 20%.

- Обновили UI на мобильных устройствах. Теперь на мобильных устройствах боковая панель будет появляться снизу.

- Улучшили утилиты для тестирования. Объединили @storybook/jest и @storybook/testing-library в один модуль @storybook/test, который основан на Vitest.

- Поддержка React Server Components. Пока что в историях можно использовать RSC только в Next.js проектах.

- Обновили версии основных зависимостей. Для Storybook 8 потребуется Node.js 18+, Vite 5 и Lit 3 версии.

https://storybook.js.org/blog/storybook-8-beta/

LLRT – среда выполнения от AWS

LLRT – облегченная среда выполнения JS от AWS. LLRT обеспечивает в 10 раз более быстрый запуск приложения и в 2 раза более низкую общую стоимость по сравнению с другими средами, работающими в AWS Lambda. По времени запуска LLRT быстрее Node.js, Bun или Deno.

LLRT написан на Rust и использует QuickJS в качестве JS движка. Хоть LLRT и не позиционирует себя в качестве замены Node.js, его API частично совместимо с API Node.js.

На данный момент вместе с LLRT есть 14 известных мне сред выполнения JS:

- Node.js (V8)
- Deno (V8)
- Bun (JavaScript core - WebKit)
- Workerd (Cloudflare, V8)
- LLRT (AWS, V8)
- WinterJS (Wasmer, Spider Money)
- Edge Runtime (Vercel, V8)
- Lagon (Vercel Acquired, V8)
- Compute @​edge (Fastly, Spider Monkey)
- Edge Compute (Alibaba V8)
- Hermes (Facebook)
- Bloomberg (v8, Internal)
- Bytedance (v8, Internal)
- txiki (QuickJS)

https://github.com/awslabs/llrt

Релиз Million.js 3

Вышел релиз Million.js 3. Подробнее что это написано здесь.

Какие изменения в новой версии:

- Улучшенная производительность. Для SSR приложений основной проблемой производительности была гидратация, ее сложность была O(n), где n – количество DOM узлов. В Million.js 3 уменьшили сложность гидратации до O(d), где d – количество динамических DOM узлов, d ≤ n:

// Million.js 3 гидратирует только handleClick и count
<div>
  <h1>Hello, world!</h1>
  <button onClick={handleClick}>{count}</button>
</div>

- Стабильность. Переписали компилятор для лучшей поддержки TypeScript, множественных возвратов, условных операторов и для обработки вложенных React компонентов.

https://million.dev/blog/million-3

Над чем работают в React Labs

В блоге React вышел новый пост о статусе работы над текущими проектами. Кратко, о чем написали:

- React Compiler готовится к релизу и уже успешно используется в проде на некоторых проектах. Компилятор будет автоматически оптимизировать код приложения, чтобы изменение стейта внутри компонента не повлекло за собой лишние ре-рендеры дочерних компонентов.

Компилятор будет оптимизировать только те компоненты, которые подходят под определенные условия. Одно из таких условий – идемпотентность компонента, т.е. всегда возвращает одинаковый результат при одном и том же наборе пропсов.

- Actions. Раньше предполагалось делать Actions, которые выполняют код на сервере – Server Actions. Сейчас API расширили и он стал называться просто Actions, поддерживая выполнение действия и на клиенте:

<form action={search}>
  <input name="query" />
  <button type="submit">Search</button>
</form>

Функцию в action можно будет определить как на сервере, используя директиву 'use server', так и на клиенте. При работе с action будут доступны хуки отслеживания состояния формы useFormStatus и useFormState.

- Директивы "use client" и "use server" будут определять «точки разделения» между окружениями. Директива "use client" будет сообщать бандлеру о необходимости генерации <noscript> (как в Astro Islands), а "use server" сообщит бандлеру о необходимости генерации POST endpoint (как в tRPC Mutations).

- Document Metadata. Появится встроенная поддержка для рендера <noscript>, <meta>, <link> в любом месте дерева компонентов, как в React Helmet.

- Загрузка ресурсов. Интеграция Suspense с жизненным циклом загрузки ресурсов, таких как стили, шрифты и скрипты.

https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024

Анимация с учетом направления в Framer Motion

При добавлении анимации на сайт бывает нужно чтобы она двигалась в разных направлениях, в зависимости от контекста. Например, при навигации между экранами надо чтобы текущий экран уезжал влево, а новый экран выезжал справа. Когда возвращаешься назад, то анимация должна быть обратной.

Чтобы сделать такую анимацию можно использовать Framer Motion и создать переиспользуемый компонент, который можно использовать для разных ситуаций. Пример использования:

export const DirectionAwareAnimationsReusableSolution = () => {
    const [product, setProduct] = useState<Product | null>(null);
    const direction: Direction = product ? 'forward' : 'back';
 
    return (<div>
        <MotionConfig transition={{ type: 'spring', duration: 0.55 }}>
            <AnimatePresenceWithDirection initial={false} mode="sync" direction={direction}>
                {product
                    ? <ProductDetails product={product} onBack={() => setProduct(null)} key="details" />
                    : <ProductsList openProduct={setProduct} key="list" />
                }
            </AnimatePresenceWithDirection>
        </MotionConfig>
    </div>);
};
 
export const ProductDetails = () => {
    const animationProps = useDirectionAnimation();
 
    return <motion.div {...animationProps}>
        {/* ... */}
    </motion.div>
});

https://sinja.io/blog/direction-aware-animations-in-framer-motion

Как использовать forwardRef с generic компонентами

Одно из ограничений forwardRef в том, что он отключает выведение типа для generic компонентов. Например:

const Table = <T,>(
  props: {
    data: T[];
    renderRow: (row: T) => React.ReactNode;
  },
  ref: React.ForwardedRef<HTMLTableElement>
) => {
  /** --snip-- */
};
 
const ForwardReffedTable = React.forwardRef(Table);

<Table
    data={["a", "b"]}
    renderRow={(row) => { // Тип выводится: row: string
      return <tr>{row}</tr>;
  }}
/>;

<ForwardReffedTable
    data={["a", "b"]}
    renderRow={(row) => { // Тип не выводится: row: unknown
      return <tr>{row}</tr>;
  }}
/>;

Чтобы исправить выведение типа для generic компонентов, можно создать утилитарную функцию для вызова forwardRef с правильными типами:

function fixedForwardRef<T, P = {}>(
  render: (props: P, ref: React.Ref<T>) => React.ReactNode
): (props: P & React.RefAttributes<T>) => React.ReactNode {
  return React.forwardRef(render) as any;
}

// Вызов forwardRef с правильным выведением типа:
const ForwardReffedTable = fixedForwardRef(Table); 

https://www.totaltypenoscript.com/forwardref-with-generic-components

React будет компилируемым

В блоге React рассказали, что React 19 будет компилируемым. В React Training объяснили, что это значит.

При использовании функциональных компонентов и хуков нужно самостоятельно мемоизировать компоненты, колбеки и переменные для предотвращения ненужных ререндеров. При использовании useCallback или useMemo нужно указывать массив зависимостей в deps, чтобы React пересоздавал функцию при изменении зависимостей.

Если использовать линтер для определения зависимостей exhaustive-deps, то он решает большинство проблем. Однако, зависимости, которые кладутся в массив, должны быть стабильными. Стабильная переменная – это переменная, которая не изменяется, если вы этого не захотите. Для стабилизации массивов, объектов и функций используется useMemo.

Для того чтобы избежать проблем с мемоизацией и определением массива зависимостей, в React 19 появится авто-мемоизация с помощью компилятора. Этот компилятор избавит разработчиков от ручной мемоизации, которая была основной проблемой при работе с функциональными компонентами и хуками.

https://reacttraining.com/blog/react-19-will-be-compiled

Чему мы научились при переходе на Next.js 14 с серверными компонентами

Medusa.js – open source проект для создания e-commerce приложений. В своем блоге они рассказали, чему научились при переходе стартового шаблона на Next.js 14 с серверными компонентами.

Одна из новых особенностей, которая требует привыкания – механизм получения данных и кэширования. Кэширование работает автоматически для fetch запросов и каждый запрос кэшируется и хранится до ревалидации. Это избавляет от проп-дриллинга и передачи значений через контекст, данные можно сразу получить через fetch из кэша.

Серверные действия – асинхронные функции, которые вызываются на клиенте и выполняются на сервере. Под капотом происходит POST запрос на сервер. Используя серверные действия, не раскрываются API ключи и не надо беспокоиться о CORS.

Серверные компоненты позволяют создать UI, который полностью рендерится на сервере. Серверные компоненты имеют доступ к БД и API, что позволяет сократить количество запросов между клиентом и сервером. Например, по умолчанию в Medusa.js на странице карточки товара все компоненты серверные, за исключением кнопки добавления корзины.

С серверными компонентами возникает проблема при получении параметров URL. Т.к. в серверных компонентах не поддерживаются хуки, то единственный вариант получения параметров URL - в page.tsx, и уже дальше передать параметры через проп-дриллинг дочерним компонентам.

https://medusajs.com/blog/client-server-transition-learnings-nextjs-14-server-components/

Избегаем ошибки гидратации с помощью useSyncExternalStore

При разработке SSR приложений может возникать ошибка:

Uncaught Error: Text content does not match server-rendered HTML.

Она связана с несоответствием контента между клиентом и сервером. Например, при рендере даты на сервере используется одна локаль 21/02/2024, а на клиенте другая локаль – пользовательская 2/21/2024.

Самый простой способ избавиться от ошибки - это использовать проп suppressHydrationWarning. Но как следует из документации React им нельзя злоупотреблять.

Другой способ – использовать useEffect для предотвращения рендера на сервере:

function LastUpdated() {
  const [isClient, setIsClient] = React.useState(false)

  React.useEffect(() => {
    setIsClient(true)
  }, [])

  if (!isClient) {
    return null
  }

  /** --snip-- */
}

Т.к. на сервере useEffect не запускается, то это рабочий способ, но не самый оптимальный. При дальнейшей навигации по сайту компонент LastUpdated будет всегда рендериться дважды, хотя в этом не будет никакой нужды. Мы уже находимся на клиенте, но LastUpdated об этом не знает.

Еще один способ – использовать useSyncExternalStore. Хоть он и предназначен для подписки на внешний стор, у него есть вторая особенность: он позволяет различать clientSnapshot и serverSnapshot. При навигации по сайту он будет сразу брать clientSnapshot, а на сервере использовать serverSnapshot. Вместо подписки на внешний стор можно передать заглушку – пустую функцию. Пример использования:

const emptySubscribe = () => () => {}

function LastUpdated() {
  const date = React.useSyncExternalStore(
    emptySubscribe,
    () => lastUpdated.toLocaleDateString(),
    () => lastUpdated.toLocaleDateString('en-US')
  )

  return <span>Last updated at: {date}</span>
}

https://tkdodo.eu/blog/avoiding-hydration-mismatches-with-use-sync-external-store

Functional UI Kit – унифицированный UI кит для Figma и React

Functional UI Kit – это UI кит для React, который содержит такие же компоненты для Figma. Для каждого компонента и его варианта есть своя история в Storybook. Между компонентами в Figma и React сохранены названия пропсов, а также сохранены одинаковые названия переменных в Figma и в CSS переменных.

При разработке библиотеки автор старался унифицировать все компоненты и использовать общие термины. Благодаря единообразию, продуктовая команда может общаться на одном языке и более быстро разрабатывать продукт.

https://functional-ui-kit.com/

Изучаем четыре ключевых примитива из Solid

Сравнение ключевых примитивов Solid и мета фреймворка Solid Start с Next.js/Remix:

- Сигналы. Детальная реактивность с помощью сигналов – суперсила Solid. Например, createAsync возвращает сигнал, который триггерит Suspense в зависимости от того, где происходит доступ к значению:

// Solid
export default function Home() {
    const nums = createAsync(() => getNums());

    return (
        <Suspense fallback="Loading...">
          {nums()}
        </Suspense>
    );
}

В React, чтобы сработал Suspense, нужно чтобы вложенный компонент был асинхронным.

- Неблокирующий Async. В Solid createAsync – неблокирующая рендер функция, т.к. для получения результата не требуется использовать async/await.

- Серверные функции. Преимущество серверных функций в возможности типизировать запросы между сервером и клиентом. Solid Start по умолчанию изоморфен, если не указана директива 'use server'. В Solid серверные функции можно вызывать внутри других серверных функций. Также во время SSR серверные функции можно вызывать внутри компонентов:

// Solid
export const getUser = async id => {
  "use server";

  return {
    user: await db.findUser(id),
    friends: getFriends(id),
  };
};

export function UserComponent(props) {
    const user = createAsync(() => getUser(props.userId));

    /** --snip-- */
}

- Серверные действия. Они предназначены для изменения данных на сервере. В Solid они отличаются от Remix. Пример:

// Solid
const addNum = action(async () => {
    "use server";

    return 'success';
}, 'addNum');

export default function Home() {
  const addNumAction = useSubmission(addNum);

  return (
    <main>
      <form action={addNum} method='post'>
        <button type="submit">Add Num</button>
      </form>
      <pre>
        {addNumAction.pending ? 'pending' : 'not pending'}
        {addNumAction.result}
      </pre>
    </main>
  );
} 

Хук useSubmission используется для вызова действия в любом компоненте приложения. Еще одно отличие от Remix в том, что можно создать несколько серверных действий и вызывать их в любых компонентах, а не только в роутах.

https://www.brenelz.com/posts/learning-four-key-primitives-in-solid/

Без внешнего margin

При создании переиспользуемых компонентов есть анти-паттерны, которые усложняют использование компонентов. Один из таких анти-паттернов – внешний margin (и иногда padding).

Внешний margin - это margin, который выходит за рамки border-box компонента. Пример:

function Card({ children }) {
  return (
    // Так нельзя, это внешний margin
    <div style={{ marginBottom: '1rem' }}>{children}</div>
  )
}

function EmployeeCard({ name, occupation }) {
  return (
    <Card>
      // Так можно, это внутренний margin
      <div style={{ marginBottom: '1rem' }}>{name}</div>
      <div>{occupation}</div>
    </Card>
  )
}

Внешний margin плох тем, что наделяет компонент ответственностью за внешнее пространство. Компонент должен отвечать только за внутреннее пространство.

Для создания пространства между компонентами используйте Flex или Grid вместе с gap в родительском компоненте.

https://kyleshevlin.com/no-outer-margin/

"react-strict-dom" – почему это круто?

Совсем недавно вышла библиотека "react-strict-dom", цель которой улучшить и стандартизировать способ написания компонентов для Web и Native приложений.

Чтобы понять, как работает эта библиотека, сначала стоит разобраться как работает существующий подход к написанию универсальных компонентов через react-native-web. В библиотеке react-native-web используются React Native компоненты. Библиотека преобразует примитивы React Native в примитивы React Dom, позволяя отображать React Native компоненты в Web.

react-strict-dom использует другой подход, в ней используется Web API для рендера компонентов. Библиотека использует полифилы для перевода примитивов в react-native и react-dom для отображения в Native и Web соответственно.

Под капотом используется stylex, пример компонента с react-strict-dom:

import React from "react";
import { css, html } from "react-strict-dom";
 
export default function App() {
  return (
    <html.div style={styles.div}>
      <html.div data-testid="testid">div</html.div>
      <html.p>paragraph</html.p>
 
      <html.div />
 
      <html.span>
        <html.a href="https://google.com">anchor</html.a>,
    </html.div>
  );
}

const styles = css.create({
  div: {
    paddingBottom: 50,
    backgroundColor: "white",
  },
});

https://szymonrybczak.dev/blog/react-strict-dom

HTML стриминг и алгоритм сравнения DOM

В последние годы все больше браузеров поддерживают стриминг HTML и JS. Во время стриминга браузер сразу рендерит HTML и исполняет JS после получения HTML фрагмента с сервера. Для активации стриминга нужно отправить браузеру правильные заголовки:

{
  "transfer-encoding": "chunked",
  "vary": "Accept-Encoding",
  "content-type": "text/html; charset=utf-8"
}

В сервера в ответе нужно использовать ReadableStream.

Есть несколько практических вариантов использования стриминга HTML. Один из них – замена HTML во время стриминга, например, как в React Suspense. Самая простая реализация React Suspense заключается в следующем: передать заглушку контента и JS скрипт для замены данных. При загрузке нужных данных передать шаблон нужного контента и вызвать функцию замены данных. Пример:

return new Response(
  new ReadableStream({
    async start(controller) {
      const suspensePromises = []

      controller.enqueue(encoder.encode('<html lang="en">'))

      /** --snip-- */

      // Передача заглушки
      controller.enqueue(
        encoder.encode('<div id="suspensed:1">Loading...</div>')
      )

      suspensePromises.push(
        computeExpensiveChunk().then((content) => {
          // Шаблон нужного контента
          controller.enqueue(
            encoder.encode(
              `<template id="suspensed-content:1">${content}</template>`
            )
          )
          // Передать скрипт для замены заглушки на нужный контент
          controller.enqueue(encoder.encode(`<noscript>unsuspense('1')</noscript>`))
        })
      )

      /** --snip-- */
    },
  })
)

Если во время стриминга HTML браузер получит JS, то он его выполнит.

Также с помощью HTML стриминга и View Transitions API можно реализовать SPA приложение, заменяя HTML без перезагрузки страницы. Если использовать алгоритмы сравнения DOM, то вместо полной замены HTML на странице можно будет менять его частично, т.е. лишь те места, которые поменялись.

https://aralroca.com/blog/html-node-streaming

Лучшие практики по написанию тестов с React Testing Library

Правильно написанные тесты не только предотвращают ошибки в коде, но и в случае React Testing Library улучшают доступность компонента. В своем блоге Алекс Хоменко собрал лучшие практики по написанию тестов с React Testing Library, кратко о них:

- Использовать *ByRole селекторы. Они наиболее надежны и работают для многих элементов. Использование *ByRole селекторов приучают к написанию доступных компонентов. Пример:

it("should submit correct form data", async () => {
  /** --snip-- */

  await user.type(screen.getByRole("textbox", { name: "Name" }), "Test");
  await user.click(screen.getByRole("button", { name: "Sign up" }));

  /** --snip-- */
});

- Использовать userEvent вместо fireEvent для симуляции событий. Хотя fireEvent работает во многих случаях, это легкая обертка над dispatchEvent. Также, в новых версиях React Testing Library рекомендуется инициализировать userEvent перед использованием:

it("should save correct data on submit", async () => {
  /** --snip-- */
  const user = userEvent.setup();
 
  await user.type(screen.getByRole("textbox", { name: "Name" }), "Test");
  /** --snip-- */
});

- Использовать findBy* вместо waitFor. Бывают случаи, когда элемент, который пытаемся использовать, недоступен при первоначальном рендеринге и появится после получения данных из API. Для таких сценариев можно использовать асинхронный селектор findBy*, который внутри себя использует waitFor. Пример:

it("renders without breaking", async () => {
  render(<ListPage />);
  expect(
    await screen.findByRole("heading", { name: "List of items" }),
  ).toBeInTheDocument();
});

- Исправление ошибки Fixing the "not wrapped in act(...)" warnings. Одной из причин ошибки может быть использование getBy* вместо findBy*, поскольку рассматриваемый элемент или компонент обновляется после асинхронного действия.
Еще одна из причин данной ошибки может быть неправильная работа с таймерами. Если компонент использует таймеры, то используйте моки для таймеров (useFakeTimers).

https://claritydev.net/blog/improving-react-testing-library-tests

Million Lint вышел в публичную бету

Million Lint – это VSCode расширение, которое выявляет медленный код и предлагает способы его оптимизации. Это как ESLint, но для производительности.

С помощью линтера можно узнать сколько времени в среднем занимает рендер компонента, как в React Devtools, но прямо в коде редактора. Также линтер дает возможность отследить размер бандла, сетевые запросы, пропсы, вызовы хуков.

Для того чтобы использовать линтер, надо установить VSCode расширение и добавить MillionCompiler, который выполняет динамический анализ отдельных компонентов. Пример настройки для Vite приложения:

import MillionCompiler from "@million/lint";
import react from "@vitejs/plugin-react";
import { defineConfig } from "vite";
 
export default defineConfig({
  plugins: [MillionCompiler.vite(), react()],
});

https://million.dev/blog/lint

В React 19 добавят diff предупреждения гидратации

В React 19 планируют писать в консоле diff предупреждения гидратации. На данный момент, в React 18, если во время гидратации клиентская и серверная разметка отличаются, то React просто предупреждает о том, что есть несоответствие UI между клиентом и сервером.

В React 19 при определении diff будет учитываться работа хука useSyncExternalStore, который позволяет возвращать разный результат для клиента и сервера.

Вместо нескольких предупреждений в консоле будет одно общее, пример:

Warning: A tree hydrated but some attributes of the server rendered HTML didn't match the client properties. This won't be patched up. This can happen if a SSR-ed Client Component used:

--snip--

  <Mismatch isClient={true}>
    <div className="parent">
      <main
+       className="child client"
-       className="child server"
+       dir="ltr"
-       dir="rtl"
      >

https://github.com/facebook/react/pull/28512