Какие компоненты в React нужны в типичном решении и за что они отвечают?

В типичном React-приложении компоненты играют разные роли, и полезно осознанно разделять их по ответственности.

Слои типичного решения

• Страницы (pages/screens) — по компоненту на маршрут: собирают данные и композируют секции. Знают о роутинге и источниках данных, почти не содержат разметки.
• Контейнеры / фичи — «умные» компоненты: загрузка данных, состояние, обработка действий пользователя. Пример: UserListContainer, который дёргает API и передаёт данные вниз.
• Презентационные (UI) компоненты — «глупые»: получают props, возвращают разметку, ничего не знают о сторе и API. Кнопки, карточки, таблицы, поля. Максимально переиспользуемые, легко тестируются и выносятся в UI-кит.
• Layout-компоненты — каркас: шапка, сайдбар, сетка. Принимают содержимое через children/слоты.
• Провайдеры — компоненты-обёртки с контекстом: тема, авторизация, стор, роутер, i18n. Обычно собраны в корне приложения.
• Служебные/граничные — ErrorBoundary (перехват ошибок поддерева), Suspense-обёртки (загрузка), гарды маршрутов (RequireAuth), порталы для модалок.

Пример композиции

<AuthProvider>
  <ThemeProvider>
    <AppLayout>
      <ErrorBoundary>
        <Suspense fallback={<Spinner />}>
          <OrdersPage /> {/* страница → контейнеры → UI-компоненты */}
        </Suspense>
      </ErrorBoundary>
    </AppLayout>
  </ThemeProvider>
</AuthProvider>

Зачем такое разделение

Тестируемость (UI-компоненты проверяются без моков API), переиспользование (кнопка не знает о заказах), управляемая сложность (логика данных не размазана по разметке). Жёсткая догма не нужна — хуки размыли границу «умный/глупый», но направление зависимостей (страница знает о UI-ките, но не наоборот) стоит сохранять.

Коротко для собеседования

Типовые роли: страницы (маршрут + сборка), контейнеры (данные и логика), презентационные компоненты (чистая разметка от props), layout (каркас с children), провайдеры (контексты в корне), граничные (ErrorBoundary, Suspense, гарды). Зависимости направлены в одну сторону: переиспользуемый UI не знает о бизнес-логике.