React и другие библиотеки не навязывают структуру проекта — решать вам. Это свобода, но и ответственность: неудачно выбранная раскладка на большом проекте превращается в клубок, где правка одной кнопки задевает пять мест. За годы у сообщества сложилось несколько устоявшихся подходов. Ни один не «правильный» — у каждого своя область применения. Разберём главные и когда какой брать.
По типам — с чего не стоит начинать
Первый инстинкт — сложить файлы по тому, чем они являются: все компоненты в components/, все хуки в hooks/, все запросы в api/. Выглядит опрятно ровно до первой реальной задачи: чтобы понять одну фичу, приходится прыгать по всем папкам сразу, а удаление фичи оставляет за собой хвосты в каждой из них. Этот подход почти всегда — тупик; остальные родились как ответ на его боль.
По фичам — прагматичный минимум
Раскладка по фичам ставит рядом всё, что относится к одной задаче: компонент, логику, запросы, типы — в одной папке features/checkout/. Плюс зона shared/ для общего и app/ для сборки. Правку одной задачи делаешь в одном месте, удаление фичи — это удаление папки.
Это разумный минимум для большинства проектов и хорошая стартовая точка. Подробно — в статье Структура React+TypeScript-проекта.
Atomic Design — про UI, а не про приложение
Atomic Design — подход к дизайн-системе, а не к приложению целиком. Он делит визуальные части по «химической» метафоре:
- атомы — кнопка, поле ввода, иконка;
- молекулы — поле поиска (поле + кнопка);
- организмы — шапка, карточка товара;
- шаблоны и страницы — компоновка организмов.
Atomic Design хорош, когда у вас развитая библиотека UI-компонентов и её надо держать в порядке. Но он говорит только про внешний вид — где живёт бизнес-логика, загрузка данных и состояние, он не отвечает. Поэтому его часто совмещают: Atomic Design внутри UI-кита, а само приложение раскладывают по фичам или по FSD.
Feature-Sliced Design — дисциплина для больших приложений
Feature-Sliced Design (FSD) — формализованная методология для приложения целиком. Она добавляет к идее «по фичам» строгие слои (shared → entities → features → widgets → pages → app) с правилом «импортировать можно только вниз» и публичные интерфейсы слайсов.
FSD стоит своих церемоний, когда приложение большое, живёт долго и над ним работает команда: единые правила снимают споры «куда это положить» и не дают зависимостям запутаться. Подробный разбор — в статье Feature-Sliced Design.
Слоёная архитектура — взгляд из бэкенда
Слоёная архитектура пришла с серверной стороны: код делят на уровни представление → логика → данные, где верхний слой зависит от нижнего, но не наоборот. На фронте это встречается в чистом виде реже — идею «однонаправленных зависимостей» у неё перенял FSD, сделав слои специфичными для интерфейса. Знать про неё полезно, потому что она объясняет, почему правило «зависим только вниз» так ценно: оно не даёт изменению в одном месте расползтись по всему приложению.
Как выбрать
Ориентир простой — по размеру и сроку жизни:
- Прототип, пара экранов — раскладка по фичам, без церемоний.
- Средний проект — по фичам + Atomic Design для UI-кита, если компонентов много.
- Большое долгоживущее приложение, команда — Feature-Sliced Design.
Подходы не исключают друг друга: типичная зрелая раскладка — FSD для приложения и Atomic Design внутри shared/ui. Начинать всегда стоит с простого и переходить к строгому, когда простое начинает мешать, а не наоборот.
Коротко
- По типам — почти всегда тупик: фича размазана по всем папкам.
- По фичам — прагматичный минимум и хорошая стартовая точка.
- Atomic Design — про порядок в UI-ките (атомы/молекулы/организмы), но не про приложение целиком.
- Feature-Sliced Design — строгие слои и правила для больших приложений.
- Слоёная — идея «зависим только вниз», которую FSD перенёс на фронт.
- Выбор — по размеру: маленькое → по фичам; большое → FSD; UI-кит → Atomic. Подходы совмещаются.
Что почитать дальше
- Feature-Sliced Design — подробный разбор слоёв, слайсов и правил импортов.
- Структура React+TypeScript-проекта — с чего начать раскладку по фичам.
- Компоненты — как строить компоненты с правильными границами.
- Состояние — где держать состояние при любой из раскладок.