Сравни подходы к разработке проекта на React и объясни, когда какой подход выбрать.

Речь о подходах к организации React-проекта — от структуры папок до способа рендеринга. Обычно ответ строят вокруг архитектуры кода.

Структура кода

По типам файлов (components/, hooks/, utils/):

• Просто и привычно; но с ростом фича «размазана» по папкам, границ нет.
• Выбирать: маленькие проекты, прототипы.

По фичам (feature-based): features/orders/{ui,model,api}:

• Каждая фича самодостаточна, легко удалять/переносить; понятны границы владения.
• Выбирать: средние и большие продуктовые приложения — фактический дефолт.

Feature-Sliced Design: слои app/pages/widgets/features/entities/shared с правилом «импорт только вниз».

• Плюс: жёсткие границы и предсказуемость в больших командах; минус — накладные расходы и порог входа.
• Выбирать: крупные приложения и команды, которым нужна дисциплина зависимостей.

Гексагональная/чистая архитектура: ядро на чистом TS, React — адаптер.

• Выбирать: богатая доменная логика (финансы, редакторы); избыточно для CRUD.

Способ рендеринга (тоже подход к проекту)

• SPA (Vite + React Router) — внутренние инструменты, дашборды за логином.
• Фреймворк (Next.js/Remix) — публичные продукты: SSR/SSG, SEO, серверные компоненты; сегодня рекомендация документации React для новых проектов.

Прочие оси выбора

• Состояние: useState/Context → Zustand/Redux при общем динамичном состоянии; серверные данные — React Query.
• Монолит против микрофронтендов (Module Federation) — последнее оправдано организационно (независимые команды/деплои), не технически.
• Тесты: RTL + Vitest, e2e Playwright на критических сценариях.

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

Структура: по типам (мелкие проекты) → по фичам (дефолт) → FSD (большие команды) → гексагональная (сложный домен). Рендеринг: SPA для внутренних инструментов, Next.js/Remix для публичных. Состояние — от useState к стору по мере надобности, сервер — React Query. Микрофронтенды — организационное решение.