Полка React и Next: данные, состояние, формы и адрес

Полка устроена так же, как вся часть: сначала то, что умеют React и Next, и только за стеной — пакет. У первых восьми строк таблицы ниже есть паспорт: когда пакет не нужен, что даёт платформа, где в учебнике своя сборка, снимок версий с датой проверки и условие, при котором строку пора пересмотреть. Остальные строки паспорта не получили — они показывают, куда смотреть.

В таблицах-снимках ниже есть столбец «Вес или цена». Килобайт там — 1024 байта после gzip: типичный импорт собран esbuild в один файл с минификацией, react и react-dom не считаются — они в проекте уже есть. Что сборщик делает с импортами по дороге, разбирает глава «Сборка», начиная со статьи «Свой сборщик». «Типичный» здесь главное слово: другой набор импортов даёт другой вес, поэтому в скобках записано, что именно импортировали. Где вес не мерили, так и сказано, и названа цена другого рода.

Строка полки стареет не по календарю, а по событию: вышел мажор, пакет пометили устаревшим, платформа догнала. Поэтому у каждого паспорта своё «Пересмотреть, если…».

Прежде чем открывать паспорта, ответьте на один вопрос: где в приложении живут данные. Серверный компонент читает их до браузера — await прямо в теле компонента, — и в клиент едет готовая разметка, а не программа, которая эти данные добудет. Два одинаковых запроса за один ответ склеивает карта начатых промисов, то есть cache() на сервере («Один и тот же запрос из двух мест»). Живёт эта карта ровно один ответ, а в браузерной сборке React cache() и вовсе пропускает вызов насквозь.

Отсюда раскладка полки. Библиотека данных нужна там, где запрос уходит из браузера: живой поиск, лента, которая подгружается при прокрутке, экран, который обновляется без перезагрузки. Если страницы читают данные на сервере, а меняют их действия, клиентский кеш запросов повторял бы работу, уже сделанную до браузера.

Вход, база и очереди в этом учебнике живут вообще не в Next, а в отдельном API части VI: там таблицы описывает схема Drizzle, а личность проверяется на каждом запросе. Поэтому Better Auth и Drizzle на этой полке паспортов не получают: их место — рядом с API.

Вопрос «где сервер» задают до выбора пакета. Ответ «данные читает серверный компонент» вычёркивает из списка кандидатов больше, чем любое сравнение библиотек.

Не нужна, если данные читает серверный компонент или хватает use() с кешем по ключу. Платформа: fetch — Widely, а ждать промис умеет сам React 19 — use() и граница Suspense.

Своя сборка в учебнике двойная. Запрос в эффекте с флагом ignore собран в «Запросе целиком», и там же честно сказано, чего в нём нет: кеша, повтора при обрыве и склейки одинаковых запросов от двух компонентов. Карта промисов для use() — в «Промис нельзя создавать в теле». Проверим обе на одной задаче: шапка и боковая панель показывают одну и ту же задачу. Прогноз: сколько запросов уйдёт на сервер?

interface Task {
  id: number;
  title: string;
}

let requests = 0;

// поддельная сеть: песочнице настоящие запросы запрещены
function fetchTask(id: number): Promise<Task> {
  requests += 1;
  return new Promise((resolve) => {
    setTimeout(() => resolve({ id, title: "Купить хлеб" }), 50);
  });
}

// запрос в эффекте, как в статье про уборку
function useTask(id: number): Task | null {
  const [task, setTask] = React.useState<Task | null>(null);
  React.useEffect(() => {
    let ignore = false;
    fetchTask(id).then((loaded) => {
      if (!ignore) setTask(loaded);
    });
    return () => {
      ignore = true;
    };
  }, [id]);
  return task;
}

function Header() {
  const task = useTask(1);
  return <h3>{task?.title ?? "…"}</h3>;
}

function Sidebar() {
  const task = useTask(1);
  return <p>в работе: {task?.title ?? "…"}</p>;
}

ReactDOM.createRoot(document.getElementById("root")!).render(
  <>
    <Header />
    <Sidebar />
  </>
);

setTimeout(() => console.log("запросов:", requests), 200);

Свой эффект на каждый вызов хука означает свой запрос на каждый компонент, который читает запись. На двух компонентах это незаметно, на двадцати — двадцать одинаковых запросов при каждом открытии экрана.

Карта по ключу склеивает их: второй читатель получает не новый запрос, а тот же начатый промис. Усложним сценарий. Пока экран открыт, задачу поправили на сервере, и приложение перерисовалось. Прогноз: что будет на экране?

interface Task {
  id: number;
  title: string;
}

let requests = 0;
const server = { title: "Купить хлеб" };

function fetchTask(id: number): Promise<Task> {
  requests += 1;
  return new Promise((resolve) => {
    setTimeout(() => resolve({ id, title: server.title }), 50);
  });
}

// кеш промисов по ключу: второй читатель получает тот же промис
const cache = new Map<number, Promise<Task>>();

function loadTask(id: number): Promise<Task> {
  let promise = cache.get(id);
  if (!promise) {
    promise = fetchTask(id);
    cache.set(id, promise);
  }
  return promise;
}

function Header() {
  const task = React.use(loadTask(1));
  return <h3>{task.title}</h3>;
}

function Sidebar() {
  const task = React.use(loadTask(1));
  return <p>в работе: {task.title}</p>;
}

function App() {
  return (
    <React.Suspense fallback={<p>Загрузка…</p>}>
      <Header />
      <Sidebar />
    </React.Suspense>
  );
}

const root = ReactDOM.createRoot(document.getElementById("root")!);
root.render(<App />);

setTimeout(() => {
  console.log("запросов:", requests);
  server.title = "Купить молоко"; // задачу поправили на сервере
  root.render(<App />);
}, 200);

setTimeout(() => {
  console.log("на экране:", document.querySelector("h3")!.textContent);
  console.log("на сервере:", server.title);
}, 400);

Карта закрывает склейку — и тут же показывает, чего в ней нет. Это и есть стена. Вопрос уже не «как кешировать», а «кто, когда и по какому событию удаляет ключ из карты»: после своей правки, при возврате в окно, по истечении срока, при ошибке — с повтором или без. Каждое такое правило — ещё десяток строк и ещё одна гонка. Вместе они и составляют TanStack Query.

Тот же сценарий на настоящем ядре TanStack Query — в Node, без React: два одновременных fetchQuery, правка на сервере, чтение из кеша и invalidateQueries.

import { QueryClient } from '@tanstack/query-core';
let requests = 0;
const server = { title: 'Купить хлеб' };
const client = new QueryClient();
const options = { queryKey: ['task', 1], queryFn: async () => { requests += 1; return { title: server.title }; }, staleTime: 60_000 };
await Promise.all([client.fetchQuery(options), client.fetchQuery(options)]);
console.log('запросов:', requests);
server.title = 'Купить молоко';
console.log('из кеша:', (await client.fetchQuery(options)).title);
await client.invalidateQueries({ queryKey: ['task', 1] });
console.log('после invalidateQueries:', (await client.fetchQuery(options)).title, '· запросов:', requests);
client.clear();

Первые две строки повторяют нашу карту: один запрос на двоих и старое значение из кеша. Третья — то, чего у карты нет: invalidateQueries помечает запись по ключу устаревшей, и следующее чтение снова идёт на сервер. Внутри @tanstack/react-query то же ядро, а useQuery подписывает компонент на запись в нём.

На сервере Next та же идея выглядит иначе: не ключ запроса, а метка, под которой копятся ключи, — «Свой кеш: ключ из входа, метка вместо списка адресов». Если данные читает сервер, сбрасывает их revalidateTag, и клиентской библиотеке здесь делать нечего.

На полке TanStack Query; SWR — запас: тот же подход «показать, что есть, и перепроверить» при меньшем весе.

Пересмотреть, если TanStack Query выпустит v6 или React даст клиентский кеш запросов с инвалидацией.

Не нужна, если хватает useReducer и контекста. Платформы у этой задачи нет, есть только React: состояние живёт в компоненте наверху, контекст раздаёт его вниз, а для источников вне React есть useSyncExternalStore.

Своя сборка: когда редьюсер честнее useState — таблица признаков; кто перерисуется, когда значение контекста сменилось, — проверка печатью каждого рендера; подписка на внешний источник — фолд про useSyncExternalStore в статье «Хук или просто функция».

Стена контекста проявляется, когда в одном значении лежат независимые куски. Соберём оба варианта рядом: контекст с объектом { count, theme } и хранилище вне React, на которое компоненты подписываются через useSyncExternalStore с селектором. Меняется только count. Прогноз: сколько раз отрисуется компонент, который показывает тему, в каждом из вариантов?

interface State {
  count: number;
  theme: string;
}

interface ProviderProps {
  children: React.ReactNode;
}

const renders = { contextCount: 0, contextTheme: 0, storeCount: 0, storeTheme: 0 };

// 1. контекст с объектом состояния
const StateContext = React.createContext<State>({ count: 0, theme: "светлая" });
let increment = () => {};

function StateProvider({ children }: ProviderProps) {
  const [state, setState] = React.useState<State>({ count: 0, theme: "светлая" });
  increment = () => setState((prev) => ({ ...prev, count: prev.count + 1 }));
  return <StateContext value={state}>{children}</StateContext>;
}

function CountFromContext() {
  renders.contextCount += 1;
  return <span>{React.use(StateContext).count} </span>;
}

function ThemeFromContext() {
  renders.contextTheme += 1;
  return <span>{React.use(StateContext).theme} </span>;
}

// 2. хранилище вне React и подписка с селектором
function createStore<T>(initial: T) {
  let state = initial;
  const listeners = new Set<() => void>();
  return {
    get: () => state,
    set(patch: Partial<T>) {
      state = { ...state, ...patch };
      listeners.forEach((listener) => listener());
    },
    subscribe(listener: () => void) {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
  };
}

const store = createStore<State>({ count: 0, theme: "светлая" });

function useStore<S>(select: (state: State) => S): S {
  return React.useSyncExternalStore(store.subscribe, () => select(store.get()));
}

function CountFromStore() {
  renders.storeCount += 1;
  return <span>{useStore((s) => s.count)} </span>;
}

function ThemeFromStore() {
  renders.storeTheme += 1;
  return <span>{useStore((s) => s.theme)}</span>;
}

ReactDOM.createRoot(document.getElementById("root")!).render(
  <StateProvider>
    <CountFromContext />
    <ThemeFromContext />
    <CountFromStore />
    <ThemeFromStore />
  </StateProvider>
);

setTimeout(() => {
  increment();
  store.set({ count: 1 });
}, 50);

setTimeout(() => {
  console.log("контекст: счётчик", renders.contextCount, "· тема", renders.contextTheme);
  console.log("хранилище: счётчик", renders.storeCount, "· тема", renders.storeTheme);
}, 200);

Значение контекста сравнивается по ссылке, поэтому новый объект перерисовывает всех читателей разом. Результат селектора сравнивается по содержимому, поэтому читатель нетронутого кусочка стоит на месте. Это и приносит Zustand: хранилище вне дерева, подписка на кусочек состояния и никаких провайдеров.

У селектора есть своя ловушка, и её стоит знать до первого проекта. Если селектор возвращает новый объект — (s) => ({ count: s.count }), — снимок при каждом чтении отличается от прошлого: React перерисовывает, снова читает, снова получает новый объект и уходит в бесконечный цикл. Примера на это здесь нет — цикл роняет его. У Zustand для такого селектора есть useShallow: он сравнивает поля объекта, а не ссылку.

Настоящий Zustand, ядро без React: подписчик получает новое и прежнее состояние и сам решает, есть ли ему дело до перемены.

import { createStore } from 'zustand/vanilla';
const store = createStore(() => ({ count: 0, theme: 'светлая' }));
let themeCalls = 0;
store.subscribe((state, prev) => { if (state.theme !== prev.theme) themeCalls += 1; });
store.setState({ count: 1 });
console.log('count:', store.getState().count, '· подписчику темы было дело:', themeCalls);

Хук, который возвращает create из zustand, делает то же сравнение за компонент — через селектор, как наш useStore.

На полке Zustand. Jotai — запас, если состояние удобнее держать отдельными атомами, а не одним объектом; его мажор 3.0.0 вышел 08.09.2026, за неделю до снимка, и выпусков исправлений у него пока нет. Redux Toolkit — запас для больших команд и старого кода: если проект уже на Redux, живая точка входа — он, а не ядро (почему — в разделе «Не на полке»). Zustand и TanStack Query — чистый JavaScript, поэтому оба стоят и на полке React Native.

Пересмотреть, если Jotai 3 наберёт выпусков исправлений или Zustand выпустит v6.

Не нужна для простых форм: action, useActionState и FormData. Платформа держит свою половину — встроенная проверка формы (required, pattern) Widely, — а React 19 берёт остальное: функция в action получает готовый FormData, а useActionState возвращает состояние после отправки.

Разбор входа тоже собран руками: одна функция на границе, на выходе значение или причина отказа («Разобрать, а не поверить», там же фолд про библиотеку разбора), и тот же принцип для любых внешних данных — «Когда данные не подошли».

Стена у форм двойная. Первая — объём: десятки полей, проверка на лету, зависимые поля, повторяющиеся группы строк. Тогда форму отдают React Hook Form или TanStack Form. Вторая — разбор: схема, написанная один раз, должна работать и в форме, и в действии, и потом на сервере API. Для второй стены у экосистемы есть общий интерфейс.

Standard Schema — не библиотека, а договор из одного свойства. Схема любой библиотеки, которая его поддерживает, кладёт в поле "~standard" объект: version, vendor с именем библиотеки, функцию validate и необязательные types для вывода типа. Потребитель — форма, действие, проверка на сервере — знает только этот объект и не импортирует ни zod, ни valibot. Одна деталь договора легко теряется: элемент пути до ошибки бывает либо ключом, либо объектом { key }, и потребитель обязан понимать оба.

Соберём потребителя и две самодельные «библиотеки» с разным видом пути. Прогноз: что напечатает пример?

// Standard Schema v1 в сокращении: так её объявляет @standard-schema/spec 1.1.0
interface StandardSchemaV1<Input = unknown, Output = Input> {
  readonly "~standard": {
    readonly version: 1;
    readonly vendor: string;
    readonly validate: (value: unknown) => Result<Output> | Promise<Result<Output>>;
    readonly types?: { readonly input: Input; readonly output: Output };
  };
}

type PathSegment = PropertyKey | { readonly key: PropertyKey };
type Result<Output> =
  | { readonly value: Output; readonly issues?: undefined }
  | { readonly issues: ReadonlyArray<{ readonly message: string; readonly path?: ReadonlyArray<PathSegment> }> };

type InferOutput<S extends StandardSchemaV1> = NonNullable<S["~standard"]["types"]>["output"];

// потребитель знает только интерфейс: форма, действие Next или проверка на сервере API
async function parseBody<S extends StandardSchemaV1>(schema: S, body: unknown): Promise<InferOutput<S>> {
  const result = await schema["~standard"].validate(body);
  if (result.issues) {
    const where = (result.issues[0].path ?? []).map((seg) => (typeof seg === "object" ? seg.key : seg)).join(".");
    throw new Error(`${schema["~standard"].vendor}: ${where} — ${result.issues[0].message}`);
  }
  return result.value;
}

interface NewTask {
  title: string;
}

// «библиотека А» кладёт в путь имя поля, «библиотека Б» — объект с key, как valibot
const schemaA: StandardSchemaV1<unknown, NewTask> = {
  "~standard": {
    version: 1,
    vendor: "мини-А",
    validate: (v) =>
      typeof (v as NewTask).title === "string" && (v as NewTask).title !== ""
        ? { value: { title: (v as NewTask).title } }
        : { issues: [{ message: "нужна строка", path: ["title"] }] },
  },
};

const schemaB: StandardSchemaV1<unknown, NewTask> = {
  "~standard": {
    version: 1,
    vendor: "мини-Б",
    validate: async (v) =>
      typeof (v as NewTask).title === "string" && (v as NewTask).title.trim() !== ""
        ? { value: { title: (v as NewTask).title.trim() } }
        : { issues: [{ message: "пустой заголовок", path: [{ key: "title" }] }] },
  },
};

async function main() {
  const task = await parseBody(schemaB, { title: "  купить хлеб " });
  console.log(task.title.toUpperCase());
  for (const schema of [schemaA, schemaB]) {
    try {
      await parseBody(schema, { title: "" });
    } catch (error) {
      console.log((error as Error).message);
    }
  }
}

main();

Все три строки прошли через parseBody, а она ни одной «библиотеки» не импортирует. Первая — удачный разбор: схема Б заодно обрезала пробелы, а у task нет своей аннотации — тип выведен из объявления схемы, поэтому toUpperCase компилятор пропускает. Две другие — отказы, и в них главная строчка: typeof seg === "object" ? seg.key : seg. Без неё отказ схемы Б напечатал бы вместо имени поля [object Object].

Это не выдумка ради примера. У настоящих zod и valibot путь выглядит так же по-разному; объект valibot для печати свёрнут в {key:title}, сам он больше — там ещё тип, вход и значение.

import * as z from 'zod';
import * as v from 'valibot';
const Task = z.object({ title: z.string().min(1, 'пустой заголовок') });
const TaskV = v.object({ title: v.pipe(v.string(), v.minLength(1, 'пустой заголовок')) });
for (const [name, schema] of [['zod', Task], ['valibot', TaskV]]) {
  const r = await schema['~standard'].validate({ title: '' });
  console.log(name, '→', JSON.stringify(r.issues.map((i) => ({ message: i.message, path: i.path.map((s) => (typeof s === 'object' ? `{key:${s.key}}` : s)) }))));
}

Кто читает интерфейс — видно по реестру. @hookform/resolvers 5.9.1 экспортирует вход ./standard-schema и держит @standard-schema/spec в peerDependencies. Это поле впервые встречается на полке, поэтому одной фразой: peerDependencies — «работаю рядом с таким-то пакетом, но в себе его не везу»; подробнее — в статье «Живой ли пакет», в вопросе о доле в нише. TanStack Form принимает Standard Schema сам, без резолвера: в его ядре есть свой валидатор под этот интерфейс. Сама спецификация — пакет из одних типов, в сборку он не попадает. Серверный валидатор с выводом типа соберём в части VI — «Собираем валидатор границы».

На полке React Hook Form с резолвером Standard Schema; TanStack Form — запас.

Пересмотреть, если React Hook Form 8 выйдет из беты (тег beta — 8.0.0-beta.3) или появится Standard Schema v2.

Не нужна в Next и Expo Router; для двух-трёх экранов хватит своего. Платформа — History API: pushState и событие popstate, Widely. На них стоял и маршрутизатор из тридцати строк, с которого начиналась глава про Next.js.

Своя сборка: маршруты своими руками — тридцать строк и таблица того, что роутер обязан уметь, — и файловый маршрутизатор целиком, который закрыл половину этой таблицы.

Стена — вторая половина той же таблицы: прокрутка и фокус при переходе, разрезание бандла по экранам, данные до отрисовки, а отдельно — ответ сервера, когда посетитель жмёт F5 на внутреннем адресе. В Next всё это решено файлами, поэтому пакет нужен приложению без Next: одностраничному приложению на Vite, встраиваемому виджету, старому проекту.

На полке React Router 8. Его мажор 8.0.0 вышел 17.06.2026, пакет только ESM ("type": "module" и ни одного входа для require), а в peerDependencies он требует react и react-dom не ниже 19.2.7 — проект на React 18 сначала обновляет React. TanStack Router — запас, если маршруты, параметры и строка запроса должны быть типизированы целиком. wouter — запас для двух-трёх экранов, когда своя сборка уже написана, а поддерживать её не хочется.

Пересмотреть, если выйдет React Router 9 или TanStack Router 2.

Не нужна для одного языка: хватит Intl.PluralRules и NumberFormat. Платформа: Intl.PluralRules — Widely с 19.03.2022, Intl.NumberFormat — тоже Widely. Своей сборки в учебнике нет, потому что Intl.PluralRules до этой полки не называла ни одна статья; её роль играет пример ниже.

В русском числа делятся на четыре категории: одна задача, три задачи, пять задач — и отдельная категория для дробей, хотя слово в ней то же, что после трёх. Правило, какое число в какую категорию попадает, движок знает сам. Прогноз: какая форма достанется числам 11, 21 и 1.5?

const rules = new Intl.PluralRules("ru-RU");

const forms: Record<Intl.LDMLPluralRule, string> = {
  zero: "задач",
  one: "задача",
  two: "задачи",
  few: "задачи",
  many: "задач",
  other: "задачи",
};

function tasks(n: number): string {
  return `${n} ${forms[rules.select(n)]}`;
}

console.log([1, 3, 5, 11, 21, 22, 1.5].map(tasks).join(", "));

Правил в коде нет: rules.select(n) возвращает категорию — one, few, many или other, — а движок выбирает её по таблицам правил CLDR, общего справочника языков, который браузер везёт с собой. Слово к категории подбираете вы. Словарь на шесть ключей нужен только ради типа: Record<Intl.LDMLPluralRule, string> требует все категории, включая zero и two, которых в русском нет.

Стена — второй язык. Появляются адреса с языком (/en/tasks), словари, которые грузятся на сервере и не должны целиком уезжать в клиент, выбор языка по заголовку запроса — это next-intl, со входами ./routing, ./server и ./navigation. Один вход требует оговорки: он называется ./middleware, но в Next 16 его подключают в файле proxy.ts, а не middleware.ts. Имя входа осталось с тех времён, когда файл назывался по-старому; документация next-intl пишет то же (сверено 14.09.2026).

Пересмотреть, если next-intl выпустит v5 или Next вернёт встроенные переводы в App Router.

Не нужна для одного-двух параметров: searchParams и useSearchParams. Платформа — URL и URLSearchParams, Widely.

Своя сборка: разбор строки запроса — откуда у searchParams тип string | string[] | undefined и почему его сужают руками — и методы useRouter: push добавляет запись в историю, replace заменяет текущую.

Стена наступает, когда в адресе живёт состояние экрана: фильтр, сортировка, номер страницы, строка поиска. Каждый параметр — сужение типа, умолчание, запись обратно в адрес и решение, нужна ли новая запись в истории на каждый введённый символ. Пять параметров — пять копий этого кода. nuqs превращает параметр адреса в подобие useState: тип и умолчание объявляются один раз, а запись в адрес по умолчанию идёт через replace.

Адаптеры в exports пакета — для Next (App Router и Pages Router), React Router, TanStack Router и обычного React, поэтому nuqs переживает и уход с Next.

Пересмотреть, если выйдет nuqs 3.

Ставить ничего не нужно: next/image, а sharp приезжает с next. Платформа делает свою часть — srcset и loading="lazy" у <img>, оба Widely, — и next/image пишет эти атрибуты за вас, а картинки нужного размера готовит сервер Next.

Кто сжимает их на сервере, видно по реестру:

npm view next@16.3.5 optionalDependencies --json

sharp стоит в optionalDependencies: npm ставит его вместе с next, а если установка не удалась, npm install не падает. Рядом — компиляторы SWC под каждую систему, и из них npm возьмёт только подходящий вашей.

Своей сборки в учебнике нет, потому что сжатие картинок — работа сервера и библиотеки на C (внутри sharp — libvips), а не React. Зато граница уже пройдена: при статическом экспорте next/image с оптимизацией роняет сборку, и нужен images: { unoptimized: true } или свой loader — сжимать картинку в момент запроса некому. Доска задач из проекта этой части экспорт не пережила бы и без картинок: её формы сделаны действиями — это разобрано в «Экспорт или Node-сервер». Свой sharp в зависимостях нужен только для собственной обработки загрузок на сервере, и это уже часть VI.

Пересмотреть, если sharp уйдёт из optionalDependencies next.

Не нужна, пока действий немного: схема и сессия прямо в действии. Платформа здесь — сам Next: действие — функция на сервере, и всё, что ей нужно проверить, проверяется в ней.

Своя сборка: каркас действия из четырёх шагов — личность, разбор входа, право, работа — и личность из сессии, а не из полей формы.

Стена — повтор. Когда действий десятки, первые шаги копируются в каждое: достать пользователя, разобрать вход схемой, вернуть отказ в одном и том же виде. next-safe-action собирает из этих шагов клиент действий: функции, добавленные его методом use() (с use() из React у этого метода общее только имя), выполняются перед каждым действием, а схема входа объявляется рядом с ним и читается через Standard Schema. В документации библиотеки такие функции называются middleware, и к файлу proxy.ts из Next 16, бывшему middleware.ts, они отношения не имеют: тот стоит перед маршрутами и видит запрос, а цепочка библиотеки работает внутри вызова действия.

У пакета один сопровождающий в реестре — это пометка о риске, а не отказ. Сами проверки при этом остаются вашими функциями и вашей схемой, а библиотека только выстраивает их в цепочку: такая зависимость меняется на границе, если с ней что-то случится.

Пересмотреть, если next-safe-action выпустит v9 или в Next появится встроенная цепочка для действий.

Эти пакеты ещё встречаются в ответах на форумах, курсах и старых проектах. У каждого — дата последнего выпуска, номер вопроса из «Живой ли пакет», на котором он отсеялся, и что брать вместо. Напомним номера: 0 — не умеет ли этого платформа, 1 — жив ли пакет, 2 — растёт ли его доля в нише.

Две строки стоит прочитать внимательнее. Formik жив по датам — вопрос 1 он проходит, — но его ниша уходит: весь реестр растёт быстрее. А react-helmet отсеян дважды: задачу, ради которой его ставили, закрыл фреймворк, и тогда уже неважно, что пакет давно молчит.

Сошедший пакет не обязательно выкорчёвывать завтра. Но новый код на нём не пишут, а при следующей большой правке экрана его меняют.

Пакеты ниже не помечены устаревшими, и у всех, кроме ядра Redux, выпуски свежие. Отказ — не оценка качества, а вопрос 4 из «Живой ли пакет», навязывает ли пакет устройство проекта, либо проверяемый факт из реестра. Честная оговорка: вопрос 4 совпадает с укладом автора учебника — стили здесь пишутся CSS-модулями, — поэтому у каждой строки названа причина, которую можно проверить.

Строка Redux отличается от остальных не случайно. Вопрос 4 к Redux Toolkit не применяется: хранилище с редьюсерами — то же устройство, что useReducer с контекстом из этой части, только вне дерева. Отказ ядру — не вкус, а слова его же авторов в его же типах.

Причина «вопрос 4» не запрещает пакет в чужом проекте. Она говорит, что сменить его позже будет стоить переписывания, и это нужно знать до установки, а не после.