Какие React навыки нужны в 2026: база, middle-уровень и интервью

Введение

Запрос какие React навыки нужны в 2026 обычно возникает в двух ситуациях. Первая - разработчик собирает план роста и не хочет тратить месяцы на темы, которые красиво выглядят в списке, но редко решают рабочие задачи. Вторая - впереди интервью, где уже недостаточно сказать "я знаю hooks". Интервьюер ждет, что кандидат понимает рендеринг, данные, производительность, границы между сервером и клиентом, тесты и и плату за выбранную архитектуру.

React в 2026 году не стал проще. Он стал системнее. Базовые компоненты, useState, useEffect, формы и списки никуда не исчезли, но вокруг них вырос слой server-first фреймворков, React Server Components, Server Functions, Actions, Suspense, streaming, React Compiler и более строгие ожидания к качеству UI. Поэтому полезнее думать не списком технологий, а слоями навыка. Сначала модель React, потом поток данных, потом архитектура приложения, потом производительность и поддержка.

Эта статья дополняет React roadmap 2026, но фокус другой: не "в каком порядке учить", а "какой навык что доказывает работодателю". Разберем базу для junior, ожидания от middle, senior-сигналы, типичные ошибки и то, как формулировать сильный ответ на интервью.

Короткая матрица навыков React разработчика в 2026

Набор навыков зависит от уровня, но фундамент везде один. Слабая база рендера ломает ответы про Compiler. Непонимание server state делает бессмысленным выбор между Redux, Zustand и React Query. Игнорирование браузера приводит к багам с фокусом, формами, доступностью и гидратацией.

Навык	Junior	Middle	Senior
Модель React	Понимает props, state, JSX, key, базовые ререндеры	Объясняет render/reconciliation/commit и причины лишних обновлений	Проектирует границы компонентов так, чтобы изменения не разносили ререндеры по дереву
Hooks	Использует useState, useEffect, useRef, useMemo без грубых ошибок	Разбирает stale closures, гонки запросов, зависимости эффектов	Задает правила для команды и выносит сложную логику в проверяемые custom hooks
Состояние	Отличает локальное состояние от глобального	Разделяет client state, server state, URL state и form state	Строит стратегию кэша, инвалидации и ownership данных между командами
Server-first	Знает, что SSR и RSC существуют	Понимает границу server/client, hydration, streaming, Server Functions	Выбирает режим рендера под продуктовые ограничения, SEO, latency и стоимость поддержки
Performance	Не создает очевидно тяжелые компоненты	Пользуется Profiler, bundle analysis, code splitting	Встраивает измерения, budgets и регрессионный контроль в процесс разработки
Тесты	Пишет базовые тесты компонентов	Тестирует поведение, async flows, формы, ошибки	Выстраивает пирамиду тестов и контракты между UI, API и дизайн-системой
Архитектура	Следует принятой структуре проекта	Делит features, shared UI, data layer и routing	Управляет эволюцией кодовой базы, миграциями и техническими рисками

На интервью эта матрица помогает не распыляться. Если вас спрашивают про useEffect, отвечайте не только синтаксисом, а связкой: зависимость, жизненный цикл запроса, отмена, гонка, cleanup, пользовательский эффект. Если спрашивают про Server Components, не уходите в лозунг "меньше JavaScript". Покажите, где проходит граница между чтением данных на сервере и интерактивностью в браузере.

База React: рендеринг, компоненты и предсказуемость

Первый обязательный навык - понимать, что React компонент не является HTML-шаблоном. Это функция, которая описывает UI для текущих входных данных. При изменении state, props или контекста React строит новое описание дерева, сравнивает его с предыдущим и применяет изменения к DOM на commit-фазе.

Без этой модели легко выучить API и все равно писать хрупкий код. Например, кандидат может знать React.memo, но не понимать, почему дочерний компонент все равно обновляется из-за новой функции в props. Или помнить, что key нужен в списках, но использовать индекс в качестве key там, где порядок элементов меняется. В результате фильтр, drag-and-drop или список сообщений начинают переиспользовать состояние не того элемента.

Минимальный набор базы:

• компоненты как чистое описание UI для входных данных;
• props как внешний контракт, state как локальная память компонента;
• key как идентичность элемента между рендерами;
• разница между render phase и commit phase;
• controlled и uncontrolled inputs;
• обработка событий и фокус;
• Error Boundaries для ошибок рендера;
• базовая доступность: labels, roles, keyboard navigation.

Хороший пример компонента скучный, зато предсказуемый:

type User = {
  id: string;
  name: string;
  role: "admin" | "member";
};

type UserListProps = {
  users: User[];
  selectedUserId: string | null;
  onSelect: (userId: string) => void;
};

export function UserList({ users, selectedUserId, onSelect }: UserListProps) {
  return (
    <ul aria-label="Пользователи">
      {users.map((user) => (
        <li key={user.id}>
          <button
            type="button"
            aria-pressed={user.id === selectedUserId}
            onClick={() => onSelect(user.id)}
          >
            {user.name} - {user.role}
          </button>
        </li>
      ))}
    </ul>
  );
}

В этом фрагменте нет сложной оптимизации, но есть важные контракты: стабильный key, явный callback, семантическая кнопка вместо кликабельного div, отсутствие мутации входного массива. Именно такие детали часто отделяют "пишу React" от "понимаю, как React будет жить в продукте".

Если на интервью просят объяснить ререндер, полезно опереться на механизм, а не на бытовую формулировку. Например: "Компонент вызывается снова, когда меняется его state, props или context value. Это еще не значит, что DOM полностью перерисуется. React построит новое дерево элементов, сравнит его с предыдущим и применит минимальные изменения на commit-фазе". Для глубины можно связать ответ с тем, когда компонент действительно перерисовывается.

Hooks: не набор рецептов, а управление временем

Hooks в 2026 году остаются базовой грамматикой React. Но ценность уже не в том, чтобы перечислить useState, useEffect, useMemo, useCallback и useRef. Ценность в том, чтобы понимать, какие данные живут между рендерами, какие вычисления должны быть чистыми, какие эффекты синхронизируют React с внешним миром и где возникает устаревшее замыкание.

useEffect особенно часто показывает уровень кандидата. Слабый ответ звучит так: "Он вызывается после рендера". Сильный ответ добавляет причину: "Эффект нужен для синхронизации с системой вне React: сетью, подпиской, таймером, DOM API. Если я просто вычисляю значение из props, эффект не нужен". Это сразу снимает часть типичных багов, где разработчик хранит производное состояние и ловит рассинхрон.

Плохой паттерн:

function SearchResults({ query }: { query: string }) {
  const [items, setItems] = useState<Result[]>([]);

  useEffect(() => {
    fetch(`/api/search?q=${query}`)
      .then((response) => response.json())
      .then(setItems);
  }, [query]);

  return <ResultsList items={items} />;
}

Этот код выглядит нормально только до первого реального пользователя. Быстрый ввод создает гонку: ответ для старого запроса может прийти позже нового и перезаписать актуальные данные. Еще нет обработки ошибки и отмены.

Более рабочий вариант:

function SearchResults({ query }: { query: string }) {
  const [state, setState] = useState<
    | { status: "idle" }
    | { status: "loading" }
    | { status: "error"; message: string }
    | { status: "success"; items: Result[] }
  >({ status: "idle" });

  useEffect(() => {
    if (query.trim().length < 2) {
      setState({ status: "idle" });
      return;
    }

    const controller = new AbortController();
    setState({ status: "loading" });

    fetch(`/api/search?q=${encodeURIComponent(query)}`, {
      signal: controller.signal,
    })
      .then((response) => {
        if (!response.ok) throw new Error("Search failed");
        return response.json();
      })
      .then((items: Result[]) => {
        setState({ status: "success", items });
      })
      .catch((error: Error) => {
        if (error.name !== "AbortError") {
          setState({ status: "error", message: "Не удалось загрузить результаты" });
        }
      });

    return () => controller.abort();
  }, [query]);

  if (state.status === "idle") return <p>Введите минимум 2 символа</p>;
  if (state.status === "loading") return <p>Загрузка...</p>;
  if (state.status === "error") return <p>{state.message}</p>;

  return <ResultsList items={state.items} />;
}

Здесь навык шире, чем "знаю effect cleanup". Разработчик моделирует состояния, отменяет устаревший запрос, кодирует query, не показывает пустой результат как успешную загрузку и не скрывает ошибку. В интервью это звучит как production-мышление, а не как пересказ документации. Для точечной подготовки полезно отдельно разобрать сложные вопросы по useEffect.

Состояние и данные: главный навык middle React

В 2026 году управление состоянием уже нельзя обсуждать как спор "Redux или Zustand". Важнее вопрос: кто владелец данных и как они обновляются. Один экран может одновременно иметь локальное UI-состояние, URL-состояние, форму, server state из API, optimistic state и кэш.

Практическое разделение:

• local UI state: открыт ли modal, выбран ли tab, виден ли dropdown;
• form state: значения полей, touched, validation errors, pending submit;
• URL state: фильтры, сортировка, page, search query, которые должны переживать reload и sharable link;
• server state: данные, загруженные с сервера, с политикой freshness, retry и invalidation;
• global client state: состояние приложения, которое не является копией ответа API, например текущая тема или draft сложного сценария.

Ошибка middle-кандидатов часто в том, что они тащат все в глобальный store. Ответ сервера кладется в Redux, фильтры тоже, локальный dropdown тоже, потом появляется ручная инвалидация, рассинхрон с URL и баги после back/forward в браузере. В небольшом проекте это еще можно терпеть. В продуктовой кодовой базе такой подход делает каждую фичу зависимой от общего состояния.

Для React-разработчика в 2026 хороший ответ про состояние звучит так: "Сначала определю владельца данных. Параметры списка положу в URL, server state отдам query cache, форму оставлю в form library или локальном состоянии, глобальный client store возьму только для состояния, которое реально нужно нескольким независимым веткам UI". Это сильнее любого перечисления библиотек.

Когда нужно выбрать между Context, Zustand, Redux Toolkit и TanStack Query, держите границу. Context не кэширует серверные данные и не решает retry. Zustand удобен для client state, но не заменяет server-state библиотеку. Redux Toolkit подходит для сложных клиентских сценариев и строгих процессов, но его цена должна быть оправдана. TanStack Query или аналогичный query layer хороши там, где нужны время устаревания (stale time), инвалидация кэша, дедупликация и background refetch. Подробный разбор этой границы есть в материале про client state и server state в React.

Server-first навыки: SSR, RSC, Actions и граница браузера

React Server Components в React 19 стабильны на уровне пользовательской модели, но реальная работа с ними почти всегда идет через framework. Это важная оговорка для интервью. Разработчику не обязательно писать собственный RSC-бандлер. Но нужно понимать, что Server Component выполняется в отдельной серверной среде, может читать данные ближе к источнику и не отправляет свой JavaScript в браузер. Client Component нужен там, где есть обработчики событий, browser API, локальное состояние и интерактивность.

Навыки, которые ожидают от middle и выше:

• отличать SSR, CSR, SSG, streaming и RSC;
• понимать hydration и причины hydration mismatch;
• не использовать browser-only API в server layer;
• проектировать границы use client;
• не передавать секреты в клиент;
• понимать, что Server Function является серверной точкой входа и требует авторизации, валидации и idempotency;
• знать, где Server Action упрощает форму, а где отдельный API endpoint читаемее и надежнее.

Типовой архитектурный пример:

// app/products/page.tsx
import { ProductFilters } from "./product-filters";
import { ProductTable } from "./product-table";
import { getProducts } from "./queries";

export default async function ProductsPage({
  searchParams,
}: {
  searchParams: Promise<{ category?: string; page?: string }>;
}) {
  const params = await searchParams;
  const products = await getProducts({
    category: params.category,
    page: Number(params.page ?? 1),
  });

  return (
    <>
      <ProductFilters initialCategory={params.category ?? "all"} />
      <ProductTable products={products} />
    </>
  );
}

// app/products/product-filters.tsx
"use client";

import { useRouter, useSearchParams } from "next/navigation";

export function ProductFilters({ initialCategory }: { initialCategory: string }) {
  const router = useRouter();
  const searchParams = useSearchParams();

  function changeCategory(category: string) {
    const next = new URLSearchParams(searchParams);
    next.set("category", category);
    next.set("page", "1");
    router.push(`/products?${next.toString()}`);
  }

  return (
    <select
      aria-label="Категория"
      defaultValue={initialCategory}
      onChange={(event) => changeCategory(event.target.value)}
    >
      <option value="all">Все</option>
      <option value="books">Книги</option>
      <option value="courses">Курсы</option>
    </select>
  );
}

Здесь серверная часть читает данные и отдает таблицу, а интерактивный фильтр живет на клиенте и меняет URL. Это не универсальный шаблон, но он показывает зрелую границу: данные не дублируются в глобальный store, URL является источником состояния фильтра, клиентский роутер не попадает в server component.

В ответе на интервью важно проговорить ограничения. RSC не заменяют client components. Server Functions не отменяют проверку прав. Streaming не исправляет медленный SQL-запрос сам по себе. SSR не гарантирует отсутствие проблем с hydration. Такая честность обычно ценится выше, чем уверенное "надо использовать Next.js".

React Compiler и производительность: меньше магии, больше измерений

React Compiler стал стабильным инструментом автоматической мемоизации, но его нельзя воспринимать как кнопку "ускорить проект". Он анализирует компоненты и hooks на build-time, опирается на правила React и лучше работает с кодом без мутаций, побочных эффектов в render и неявных зависимостей. Это меняет не только оптимизацию, но и стиль кода.

Практический навык 2026 года - писать компоненты, которые компилятор может безопасно анализировать:

• не мутировать props и внешние объекты во время render;
• не писать во внешние переменные из компонента;
• держать render чистым;
• выносить side effects в эффекты, actions или data layer;
• не лечить каждый ререндер ручным useMemo;
• проверять оптимизацию в React DevTools и профилере, а не по ощущениям.

Слабый подход к performance: "Добавлю memo, useMemo и useCallback". Сильный подход: "Сначала измерю. Если проблема в большом списке, проверю virtualization и гранулярность рендера. Если в тяжелом вычислении, вынесу и закэширую. Если в bundle, посмотрю code splitting и tree shaking. Если в сетевом каскаде, поменяю загрузку данных".

Симптом	Что проверить первым	Частая ошибка	Более сильное решение
Медленный ввод в форме	Ререндерится ли тяжелая часть дерева на каждый символ	Оборачивать все callbacks в useCallback	Локализовать состояние поля, отделить тяжелый preview, добавить deferred rendering при необходимости
Долгая первая загрузка	Bundle size, route chunks, hydration cost	Оптимизировать только React-компоненты	Code splitting, lazy routes, server rendering, меньше client components
Медленный список	Количество DOM-узлов, key, row rendering cost	Использовать index как key и memo	Стабильный id, virtualization, пагинация, memo только после профиля
Дубли запросов	Query ownership и cache policy	Копировать server state в store	Query cache, deduplication, stale time, invalidation
Hydration mismatch	Различия server/client render	Скрывать warning	Убрать nondeterministic render, перенести browser-only часть в client boundary

На middle-интервью по performance часто проверяют не знание одной библиотеки, а диагностику. Поэтому полезно уметь объяснить последовательность: воспроизвести симптом, измерить в Profiler, найти фазу, сформулировать гипотезу, внести малое изменение, сравнить результат. Для углубления рядом хорошо ложится статья про поиск узких мест в React performance.

TypeScript, формы и контракты UI

React-разработчик в 2026 почти всегда работает с TypeScript. Но интервьюеры все реже спрашивают абстрактные conditional types и все чаще смотрят, как типы защищают UI от невозможных состояний. Особенно это видно в формах, async flows и компонентах дизайн-системы.

Простой пример: форма профиля может быть в режиме чтения, редактирования, отправки, ошибки и успешного сохранения. Если представить это набором boolean-полей, состояния начнут конфликтовать: isSaving и isSuccess одновременно, ошибка при пустом draft, кнопка активна во время submit. Discriminated union дешевле и надежнее.

type ProfileFormState =
  | { mode: "view"; profile: Profile }
  | { mode: "edit"; draft: ProfileDraft }
  | { mode: "saving"; draft: ProfileDraft }
  | { mode: "error"; draft: ProfileDraft; message: string };

function canSubmit(state: ProfileFormState) {
  return state.mode === "edit" && state.draft.name.trim().length > 0;
}

Такой код показывает навык проектирования состояния, а не просто знание синтаксиса. Он помогает тестам, ревью и будущим изменениям. Когда продукт добавит "pending email confirmation" или "readonly by permissions", типы подскажут, где нужно обновить UI.

Формы - отдельный маркер зрелости React-разработчика. Нужно понимать controlled/uncontrolled inputs, работу с FormData, валидацию на клиенте и сервере, pending states, optimistic UI, accessibility ошибок, фокус на первое невалидное поле. В React 19 Actions и useActionState делают часть сценариев проще, но не отменяют UX-контракт: пользователь должен видеть, что отправка идет, что именно сломалось и можно ли безопасно повторить действие.

Тестирование, доступность и надежность

В 2026 году "умею тестировать React" означает не "могу проверить, что компонент отрендерился". Надежный тест привязан к пользовательскому поведению и контрактам UI. Он ищет кнопку по роли, вводит текст, отправляет форму, проверяет сообщение об ошибке, учитывает async state. Такой тест переживает внутренний рефакторинг лучше, чем проверка приватного state или структуры компонентов.

Минимальный набор:

• unit-тесты для чистых функций и сложных вычислений;
• component tests через Testing Library для пользовательских сценариев;
• integration tests для формы, роутинга и API-mocking;
• E2E для критических потоков;
• accessibility checks для клавиатуры, labels, focus management и modal behavior;
• Error Boundaries и fallback states для runtime-ошибок.

Тесты особенно важны на границах: query cache, optimistic update, retry, permissions, feature flags, server/client split. Там больше всего скрытых состояний. Если команда добавила Server Function для формы, тест должен покрыть не только happy path, но и ошибку валидации, отсутствие прав и повторную отправку.

Хороший ответ на интервью: "Я не тестирую implementation details компонента. Я фиксирую пользовательский контракт: что видно, что доступно с клавиатуры, какой запрос уходит, что происходит при ошибке. Для data layer использую mock server, чтобы тест был ближе к реальному API". Это сразу звучит взрослее, чем "покрою snapshot".

Архитектура React-приложений: границы важнее папок

Архитектура в React - это не только структура папок. Это решение о том, где живут данные, какие компоненты имеют право знать о роутинге, как feature общается с shared UI, где проходит граница server/client, как вводятся эксперименты и как команда удаляет старый код.

Middle-разработчик должен уметь объяснить локальную архитектуру экрана. Senior - эволюцию системы. Например, как разбить большой SPA на маршруты, как не превратить Context в скрытый глобальный store, как вынести data fetching из UI без потери читаемости, как подключить дизайн-систему без копипасты бизнес-логики в shared components.

Здоровые признаки React-архитектуры:

• feature не импортирует соседнюю feature напрямую без явного контракта;
• shared UI не знает о бизнесовых API;
• data layer скрывает транспортные детали, но не прячет ошибки;
• route boundary отвечает за загрузку и layout, а не за всю бизнес-логику;
• server/client границы видны в коде и понятны на ревью;
• feature flags имеют путь удаления;
• сложные custom hooks покрыты тестами или хотя бы имеют узкий контракт.

На собеседовании архитектурный вопрос часто звучит как "как бы вы спроектировали экран". Не стоит начинать с библиотек. Начните с требований: частота обновления данных, SEO, права доступа, интерактивность, offline, размер списка, ошибка сети, требования к first render. Потом предложите схему. Такая последовательность показывает, что вы проектируете под задачу, а не под любимый стек. Для React-проектов с ростом кодовой базы рядом полезен разбор масштабируемой frontend-архитектуры.

Частые ошибки при прокачке React навыков

Первая ошибка - учить новые API поверх слабой базы. Если разработчик не понимает key, устаревшие замыкания и controlled input, Server Components не сделают его сильнее. Они просто добавят новый слой путаницы.

Вторая ошибка - путать server-first с отказом от клиента. Интерактивность, состояние браузера, drag-and-drop, canvas, rich text editor, карты, сложные формы и realtime UI остаются клиентскими задачами. Server Components хороши там, где чтение данных и размер JavaScript важнее локальной интерактивности.

Третья ошибка - оптимизировать без измерений. Лишний useMemo может усложнить код и не дать результата. Иногда узкое место не в React, а в сетевом каскаде, тяжеловесной библиотеке, плохом API или тысяче DOM-узлов.

Четвертая ошибка - копировать server state в global store. Это почти всегда приводит к ручной инвалидации, рассинхрону и спору "почему UI показывает старые данные". Server state требует кэша, политики свежести и понятного ownership.

Пятая ошибка - забывать про браузер. React не отменяет HTML, CSS, формы, фокус, дерево доступности, event loop, performance navigation timing и ограничения мобильных устройств. Кандидат, который умеет строить UI только через компоненты, но не понимает платформу, быстро упирается в реальные баги.

Как отвечать на интервью про React навыки в 2026

Хороший ответ строится не по схеме "я знаю X, Y, Z", а по схеме "задача - механизм - решение - ограничение". Например, на вопрос "что нужно знать React-разработчику сейчас" можно ответить так:

"Я бы разделил навыки на слои. Сначала база React: рендеринг, props/state, key, hooks, формы и эффекты. Затем работа с данными: где local state, где URL, где server state и query cache. После этого modern React: SSR, streaming, Server Components, Server Functions, Actions и Suspense, но с пониманием границы клиента и сервера. Отдельно нужны performance через измерения, TypeScript для UI-контрактов, тесты пользовательского поведения и архитектура feature-уровня. Новые API важны, но они не заменяют базовую модель React".

Если интервьюер просит оценить ваш уровень, не отвечайте только годами опыта. Привяжите уровень к ответственности:

• junior: могу реализовать экран по понятному дизайну, не ломая базовые контракты;
• junior+: могу сам разобрать форму, запросы, ошибки и простую оптимизацию;
• middle: могу выбрать владельца данных, спроектировать feature, объяснить tradeoffs и диагностировать performance;
• senior: могу задавать архитектурные правила, вести миграции, снижать риски и обучать команду через ревью.

Такой ответ помогает интервьюеру понять, где вы полезны в команде. Он также снижает риск ловушки, когда кандидат перечисляет модные темы, а потом не может объяснить, почему useEffect сделал лишний запрос.

Практический план развития на 6 недель

Если цель - быстро закрыть пробелы перед интервью, не пытайтесь учить все параллельно.

1. Неделя 1: модель React, ререндеры, key, формы, controlled inputs, базовый TypeScript.
2. Неделя 2: hooks, useEffect, stale closures, cleanup, async requests, custom hooks.
3. Неделя 3: состояние, URL params, query cache, Redux/Zustand/Context как разные инструменты, а не взаимозаменяемые ответы.
4. Неделя 4: SSR, hydration, RSC, Server Functions, Actions, Suspense, граница server/client.
5. Неделя 5: performance, React DevTools Profiler, bundle analysis, code splitting, virtualization, Compiler.
6. Неделя 6: тесты, accessibility, архитектурные вопросы, устные ответы по реальным сценариям.

Каждую неделю лучше завершать маленьким результатом: экран поиска с отменой запросов, форма с валидацией, таблица с фильтрами в URL, SSR-страница с client filter, профилирование списка, тесты на ошибку и pending state. Интервью проверяет не только память. Оно проверяет, можете ли вы собрать систему из отдельных навыков.

FAQ

Нужно ли в 2026 учить React с нуля через чистый React или сразу через Next.js?

Лучше разделить слои. Чистый React нужен для модели компонентов, рендера, hooks и состояния. Next.js или другой framework нужен для маршрутов, SSR, RSC, загрузки данных и деплоя. Если начать только с framework, легко выучить файловые conventions и не понять, что делает React.

Какие навыки обязательны для junior React разработчика?

Junior должен уверенно писать компоненты, работать с props/state, списками, key, событиями, controlled inputs, базовыми hooks, простыми запросами и TypeScript для props. Плюсом будет понимание accessibility, тестов поведения и того, почему не каждый state должен быть глобальным.

Что нужно добавить, чтобы выйти на middle?

Middle-уровень начинается там, где разработчик сам выбирает архитектуру feature. Нужно понимать server state, query cache, URL state, гонки запросов, оптимизацию по измерениям, тесты пользовательских сценариев, SSR/RSC на уровне tradeoffs и границы ответственности компонентов.

Нужно ли знать Redux в 2026?

Да, но не как единственный правильный store. Важно понимать, где Redux Toolkit оправдан: сложные клиентские сценарии, строгая трассируемость изменений, большой shared state. Для server state чаще нужен query layer, а для небольшого client state может хватить Context, Zustand или локального состояния.

Какие React темы чаще всего проверяют на интервью?

Часто спрашивают ререндеры, reconciliation, key, useEffect, формы, controlled/uncontrolled inputs, мемоизацию, Context, server state, React Query, SSR/CSR/RSC, hydration, Suspense, performance, тестирование и архитектуру экранов. На middle и выше почти всегда ждут компромиссы, а не только определения.

React Compiler делает useMemo и useCallback ненужными?

Нет. Compiler автоматизирует часть мемоизации, но ручные инструменты остаются для случаев, где нужен точный контроль, например стабильная зависимость эффекта или дорогой расчет вне типового компонентного сценария. Главное - не использовать memoization как рефлекс без профилирования.

Итоги

React навыки в 2026 - это не набор модных названий. Работодателю нужен разработчик, который понимает модель рендера, управляет состоянием без рассинхрона, строит границы между сервером и клиентом, пишет проверяемый UI, измеряет производительность и умеет объяснять tradeoffs.

Для junior важнее всего крепкая база: компоненты, hooks, формы, TypeScript, простые запросы и аккуратный UI. Для middle решающими становятся ownership данных, архитектура feature, performance-диагностика, server-first мышление и тесты. Для senior - способность задавать правила, вести миграции и снижать системные риски.

Если свести статью к одной фразе: учите React не как набор API, а как модель построения интерфейса во времени. Тогда новые инструменты вроде Server Components, Actions и Compiler становятся не шумом, а продолжением уже понятной картины.