Когда проект разрастается до десятков экранов, а папка helpers
начинает весить больше, чем хотелось бы, приходит время пересмотреть подход к архитектуре. В этой статье — как я пришёл к принятию Feature-Sliced Design на React. Только личный опыт, ошибки и выводы.
Отрицание
Ты слышишь про Feature-Sliced Design, думаешь: ага, ещё один способ переименовать components
и utils
. Открываешь доку, видишь: features
, entities
, shared
, widgets
, pages
. Думаешь: ну ясно-понятно, но у меня всё и так нормально. Потом вспоминаешь, что у тебя проект на 50 экранов, файл helpers
весит как «Война и мир». И как бы вроде всё работает, но внутри сомневаешься.
Торг
Ладно, заведу папку features
, но components
оставлю — вдруг надо.
Окей, заведу entities
, но useAuth
пока в hooks. api
вроде бы shared
, но иногда оно лежит в lib
. А ещё у меня есть UIKit, и там почему-то тоже кнопки.
Начинается микс стилей: половина проекта по FSD, половина — как чувствуешь.
Ты открываешь useProductData
, думаешь: он в shared
, или в features
, или в entities
?
И закрываешь IDE, потому что мозг перегрет.
Депрессия
Ты решил делать всё по канону.
Создал widgets
, добавил shared/lib
, сделал model/types
.
Разбил features, создал entities
на каждую сущность.
Ввёл shared/model/store
.
Вынес react-query
в shared
.
Переименовал types
в model
.
Всё вроде красиво, но ничего не радует.
У тебя relative import hell.
Команда не понимает, что где лежит.
Новичок спрашивает, где лежит кнопка, а ты просто молчишь.
А ещё кто-то в доке пишет, что можно завести processes, но это не точно.
И ты сидишь и не уверен, что хочешь продолжать писать фронтенд.
Принятие
Ты перестаёшь следовать доке как библии. Делаешь так, как удобно. Оставляешь только то, что работает.
В shared
— только общее.
В entities
— только бизнес-логика.
В features
— только действия.
В widgets
— только блоки.
В pages
— только маршруты.
В app
— точка входа и зависимости.
Ты начинаешь думать фичами. Компоненты становятся переиспользуемыми. У тебя больше нет свалки. Ты понимаешь, что наконец-то можешь жить.
Плюсы
— Масштабируемость
— Изолированность
— Понятная ментальная модель
— Структура для команды
— Лёгкость сопровождения
Минусы
— Высокий порог входа
— Иногда слишком много слоёв
— Архитектурный overkill на мелких проектах
— Непонятно, куда класть модалки и утиль
Feature-Sliced Design — это не волшебная таблетка, а просто инструмент. Если ты делаешь простой лендос, можешь смело забыть про всю эту архитектуру. Но если у тебя сложная админка или большой продукт — тогда FSD может реально помочь. Только не надо слепо следовать документации. Делай так, как удобно тебе и команде. Иначе боль.