Что такое паттерн React?

Фундамент, на котором стоит каждый паттерн React: UI — это функция состояния, UI = f(state). Ты не мутируешь DOM императивно; ты декларируешь, как должен выглядеть UI для текущего состояния, а React сверяет и обновляет. Каждый паттерн в этом треке — разный ответ на одни и те же два вопроса, вытекающих из этой модели: где живёт состояние? и как рендеринг составлен из него?

// вся модель в одной строке: дано состояние — опиши UI
function Counter({ count }: { count: number }) {
  return <p>Count: {count}</p>;
}

Держи это в голове: «композиция», «колокация состояния», «граница сервер/клиент» — не разрозненные трюки, а всё про то, как хорошо формировать f и располагать state.

Паттерн — это именованное переиспользуемое решение повторяющейся задачи, и имя — половина ценности. «Подними это состояние вверх», «сделай эти compound-компоненты», «вынеси кастомный хук», «поставь error boundary над этим Suspense» — каждое называет проблему, с которой ты встретишься не раз, и форму, которая её решает. Имя позволяет команде сказать что делать тремя словами и рассуждать о компромиссах, не выводя их заново. Паттерн — не библиотека и не сниппет для вставки; это проектное решение с известными последствиями.

Повторяющиеся задачи, которые решают паттерны в React, группируются в несколько семейств:

• Композиция — как компоненты соединяются (children, слоты, compound-компоненты, render-props).
• Состояние — где живёт состояние и как оно течёт (колокация, подъём, контекст, внешние сторы).
• Эффекты и производительность — синхронизация с внешним миром и отсутствие лишних перерисовок.
• Границы — сервер против клиента, Suspense, error boundaries, формы и actions, загрузка данных.

Паттерны важнее по мере роста приложения, потому что сложность накапливается. Приложение из 5 компонентов терпит почти любую структуру. На 500 компонентах плохой выбор — состояние, хранимое слишком высоко, так что перерисовывается всё; логика, продублированная по компонентам; божественный компонент, владеющий десятью обязанностями, — умножается в тысячи ненужных рендеров, запутанную связанность изменений и фичи, которые никто не может добавить безопасно. Паттерны — это то, как ты держишь стоимость следующего изменения плоской, а не позволяешь ей загибаться вверх по мере роста кода.

// плохо масштабируется: один компонент владеет загрузкой, фильтрацией,
// сортировкой, пагинацией, выбором и рендерингом — каждое изменение трогает всё
function UserTable() { /* 400 строк, 9 useState, 4 эффекта */ }

// хорошо масштабируется: каждая обязанность — составная часть с одной задачей
// <DataTable> + useUsers() + <Toolbar> + <Pagination>

Паттерны не нужны, чтобы маленькое работало. Они нужны, чтобы большое оставалось изменяемым.

Senior-тест для любого паттерна: делает ли он вероятное следующее изменение дешевле — не переплачивая сейчас? У каждого паттерна есть цена: косвенность, больше файлов, концепция для изучения. Compound-API великолепен для виджета Tabs, переиспользуемого по всему приложению, и абсурден для одноразового ряда из двух кнопок. Контекст решает проброс пропсов и, применённый неверно, перерисовывает полдерева на каждое нажатие клавиши. Поэтому дисциплина не «применяй паттерны», а «подбирай паттерн под давление». Спроси: что здесь вероятно изменится или будет переиспользовано, и делает ли этот паттерн именно это дешёвым, оставаясь простым для всего остального?

Этот трек учит каждому паттерну вместе с его режимом отказа — когда он окупается, а когда это переусложнение, — чтобы ты тянулся к нужному, а не к самому вычурному.