Как стать автором
Обновить

Отрицание, торг, депрессия и принятие: путь фронтендера к Feature-Sliced Design на React

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров3.9K

Когда проект разрастается до десятков экранов, а папка 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 может реально помочь. Только не надо слепо следовать документации. Делай так, как удобно тебе и команде. Иначе боль.

Теги:
Хабы:
+3
Комментарии7

Публикации

Работа

Ближайшие события