FSD-шные заметки 📝

Вот мои мысли о методологии Feature-Sliced Design, основанные на практике. Её ключевая идея - группировка файлов в файловой структуре проекта по бизнес-логике и функциональности. Это не строгий свод правил, а набор рекомендаций, и слепое следование им часто вредит.

Классическая ошибка - создавать в слое shared папки по техническому признаку, например, hooks или constants. Методология предлагает другой подход: группировать файлы по решаемой задаче. Всё, что относится к уведомлениям, должно быть в shared/lib/notifications, а логика валидации - в shared/lib/validation. Эта папка может содержать компоненты, утилиты и типы - главное, чтобы они решали одну задачу.

Ещё один частый промах - создавать для каждой сущности вроде order одноимённые папки на всех уровнях файловой структуры: features/orders, widgets/orders. Это неверно. Согласно методологии, папка в entities действительно содержит сущность, а на уровнях выше (features, widgets) группировка должна быть по функциональности, например, features/cancelling.

Что касается файлов index.ts для публичного API, то они полезны в больших проектах, но внутри одного модуля их лучше не использовать. Ответа на вопрос «где размещать запросы к API или функции-мапперы» в методологии нет - это зависит от проекта.

В этом и суть: FSD задаёт общую логику организации файлов и папок, но конкретные решения нужно принимать, исходя из контекста. #fsd #ui