В React устаревает не только API, но и способ начать проект. На 25 мая 2026 года официальная документация ведет по ветке React 19.2, а GitHub releases и npm registry показывают пакетную версию React 19.2.6, выпущенную 6 мая 2026 года. Поэтому первый фильтр для любого туториала простой: если он начинает новый проект через Create React App, его нельзя брать как маршрут по умолчанию.
Официальная страница Installation прямо помечает Create React App как deprecated. Отдельный пост Sunsetting Create React App объясняет, почему это важно: старый starter давал быстрый dev server и build, но не закрывал routing, data fetching и code splitting для реального приложения. Старый урок может быть полезен для JSX, но он не должен диктовать стек в 2026 году.
Первый рабочий вариант - идти через react.dev Learn и Reference. Это лучший путь, если задача - понять components, props, state, effects, hooks и Rules of React без лишней архитектуры. Reference Overview показывает актуальные разделы Hooks, Components, React DOM APIs и React Compiler для версии 19.2. Rules of React отдельно подчеркивает: это правила, а не мягкие советы; при нарушении код обычно становится багованным и трудным для анализа.
Такой маршрут хорош для первых двух недель. Сначала components и JSX, затем state, lists, forms, effects и refs. После этого уже можно читать API Reference по конкретному вопросу: `useState`, `useEffect`, `useTransition`, `createRoot`, `hydrateRoot`, server APIs. Ошибка многих старых материалов в том, что они учат "React вообще", а не проверяют, есть ли API в текущей ветке документации.
Второй вариант - начинать новое приложение через framework. Страница Creating a React App рекомендует framework для нового приложения или сайта. Там же есть важное уточнение: full-stack frameworks не требуют сервер во всех сценариях; они могут поддерживать client-side rendering, single-page apps и static-site generation. Поэтому выбор framework не равен автоматическому усложнению инфраструктуры, если проекту нужны маршруты, загрузка данных и deploy path.
На этой развилке не нужен спор "Next.js против всего". Официальная страница приводит Next.js App Router, React Router v7 и Expo как рекомендуемые маршруты для разных задач. Практический вопрос другой: нужно ли приложению routing с URL, data loading, code splitting, server rendering или native mobile target. Если да, framework route честнее старого туториала, где все маршруты держатся в `useState`.
Третий вариант - сборка с нуля через build tool. React не запрещает его: пост про Create React App прямо говорит, что для необычных ограничений, собственного framework или учебной сборки можно использовать Vite, Parcel или Rsbuild. Но этот вариант требует дисциплины. Routing, data fetching и code splitting придется выбрать отдельно, а не считать, что bundler уже решил архитектуру приложения.
Release notes нужны не в конце, а перед копированием современных примеров. React 19 Upgrade Guide требует новый JSX transform для React 19 и дает codemods для распространенных замен. React 19.2 release post вводит ``, `useEffectEvent` и `cacheSignal`; там же есть ограничение: `useEffectEvent` нужен для логики события внутри Effect, а не как способ заставить linter замолчать. Это именно тот тип деталей, который редко живет в старом блоге.
Если React используется с TypeScript, проверка версий добавляется к основному маршруту. На дату проверки npm registry показывает `@types/react` 19.2.15, а документация имеет отдельный раздел Using TypeScript. Это не значит, что нужно начинать React с типов. Это значит, что туториал с TypeScript должен синхронизировать `react`, `react-dom` и `@types/react`, а не смешивать примеры из React 17, React 18 и React 19.
Практический маршрут без галлюцинаций выглядит так. Сначала открыть react.dev и зафиксировать текущую ветку документации. Затем выбрать цель: изучение компонентов, новый production app, scratch setup или upgrade существующего проекта. После этого сверить стартовый шаблон, имена API, JSX transform, lint rules и package versions с официальными страницами. Блог можно оставить как объяснение конкретного приема, но решение о стеке и миграции должны принимать документация, release notes и GitHub releases.
Источник обложки: https://commons.wikimedia.org/wiki/File:Programmer_at_work_(Unsplash).jpg
Читайте также: