Feature slice design

Feature Slice Design (FSD) — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения.

Основные идеи FSD:

1. Организация по фичам, а не по типам файлов:
   • Вместо традиционного разделения на папки типа components, pages, store, код организуется вокруг функциональных блоков (фич).
   • Например, для фичи "Корзина покупок" создаётся отдельная папка, внутри которой находятся все связанные с ней компоненты, стили, логика и тесты.
2. Изоляция функциональности:
   • Каждая фича (срез) максимально независима от других. Это позволяет разрабатывать, тестировать и изменять её без влияния на остальные части приложения.
3. Переиспользуемость:
   • Общие части (например, UI-компоненты или утилиты) выносятся в отдельный слой, который может использоваться несколькими фичами.
4. Масштабируемость:
   • По мере роста приложения новые фичи добавляются как отдельные модули, что упрощает поддержку и развитие проекта.

Пример структуры проекта с использованием FSD:

src/
│
├── features/
│   ├── cart/              # Фича "Корзина"
│   │   ├── components/    # Компоненты, специфичные для корзины
│   │   ├── hooks/         # Хуки для корзины
│   │   ├── store/         # Логика состояния (например, Redux slice)
│   │   └── index.ts       # Экспорт фичи
│   │
│   └── auth/              # Фича "Авторизация"
│       ├── components/
│       ├── hooks/
│       ├── store/
│       └── index.ts
│
├── shared/                # Общие компоненты и утилиты
│   ├── ui/                # UI-компоненты (кнопки, инпуты и т.д.)
│   └── lib/               # Утилиты и хелперы
│
└── app/                   # Основная логика приложения (роутинг, провайдеры и т.д.)

Понятия

Слои, слайсы и сегменты образуют иерархию, как показано на схеме:

На картинке выше: три столбика, обозначенные слева направо как "Слои", "Слайсы" и "Сегменты" соответственно.

Столбик "Слои" содержит семь делений, расположенных сверху вниз и обозначенных "app", "processes", "pages", "widgets", "features", "entities" и "shared". Деление "processes" зачеркнуто. Деление "entities" соединено со вторым столбиком "Слайсы", показывая, что второй столбик является содержимым "entities".

Столбик "Слайсы" содержит три деления, расположенных сверху вниз и обозначенных "user", "post" и "comment". Деление "post" соединено со столбиком "Сегменты" таким же образом, что и содержимое "post".

Столбик "Сегменты" содержит три деления, расположенных сверху вниз и обозначенных "ui", "model" и "api".

Слои

Слои стандартизированы во всех проектах FSD. Вам не обязательно использовать все слои, но их названия важны. На данный момент их семь (сверху вниз):

1. App — всё, благодаря чему приложение запускается — роутинг, точки входа, глобальные стили, провайдеры и т. д.
2. Processes (процессы, устаревший) — сложные межстраничные сценарии.
3. Pages (страницы) — полные страницы или большие части страницы при вложенном роутинге.
4. Widgets (виджеты) — большие самодостаточные куски функциональности или интерфейса, обычно реализующие целый пользовательский сценарий.
5. Features (фичи) — повторно используемые реализации целых фич продукта, то есть действий, приносящих бизнес-ценность пользователю.
6. Entities (сущности) — бизнес-сущности, с которыми работает проект, например user или product.
7. Shared — переиспользуемый код, особенно когда он отделён от специфики проекта/бизнеса, хотя это не обязательно.

Слои App и Shared, в отличие от других слоев, не имеют слайсов и состоят из сегментов напрямую.

Фишка слоев в том, что модули на одном слое могут знать только о модулях со слоев строго ниже, и как следствие, импортировать только с них.

Слайсы

Дальше идут слайсы, они делят слой по предметной области. Вы можете называть ваши слайсы как угодно, и создавать их сколько угодно. Слайсы помогают не теряться в проекте, потому что группируют тесно связанный по смыслу код.

Слайсы не могут использовать другие слайсы на том же слое, и это обеспечивает сильную связанность кода внутри слайса и слабую сцепленность между слайсами.

Сегменты

Слайсы, а также слои App и Shared, состоят из сегментов, а сегменты группируют код по его назначению. Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей:

• ui — всё, что связано с отображением: UI-компоненты, форматтеры дат, стили и т.д.
• api — взаимодействие с бэкендом: функции запросов, типы данных, мапперы.
• model — модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
• lib — библиотечный код, который нужен другим модулям этого слайса.
• config — файлы конфигурации и фиче-флаги. Обычно этих сегментов достаточно для большинства слоев, поэтому свои собственные сегменты обычно создают только в Shared или App, но это не жёсткое правило.

Преимущества

• Однородность
  Поскольку структура стандартизирована, проекты становятся более единообразными, что облегчает набор новых участников в команду.
• Устойчивость к изменениям и рефакторингу
  Модуль на одном слое не может использовать другие модули на том же слое или слоях выше.
  Это позволяет вам вносить изолированные правки без непредвиденных последствий для остальной части приложения.
• Контролируемое переиспользование логики
  В зависимости от уровня вы можете сделать код либо очень переиспользуемым, либо очень локальным.
  Это сохраняет баланс между соблюдением принципа DRY и практичностью.
• Ориентация на потребности бизнеса и пользователей
  Приложение разделено на бизнес-домены, и при именовании поощряется использование терминологии бизнеса, чтобы вы могли делать полезную работу в продукте, не вникая полностью во все другие несвязанные части проекта.

Когда использовать Feature Slice Design

• В крупных проектах с большим количеством функциональных блоков.
• В командах, где разные разработчики работают над разными фичами.
• Когда требуется высокая степень переиспользуемости и модульности.

Преимущества FSD:

• Упрощение разработки: Легче фокусироваться на одной фиче, не отвлекаясь на остальные части приложения.
• Улучшение поддерживаемости: Изменения в одной фиче не затрагивают другие.
• Гибкость: Фичи можно легко добавлять, удалять или заменять.
• Тестируемость: Каждая фича может быть протестирована изолированно.

Когда использовать FSD:

• В крупных проектах с множеством функциональных блоков.
• Когда требуется высокая степень переиспользуемости и модульности.
• В командах, где разные разработчики работают над разными фичами.

Альтернативы:

• Layer-based architecture (разделение на слои, например, components, pages, store).
• Domain-driven design (DDD) (организация кода вокруг доменных областей).

🚀 Источник: DeepSeek