Feature-Sliced Design
Що таке Feature-Sliced Design (FSD)
Feature-Sliced Design (FSD) - це архітектурний підхід до організації фронтенд-проєкту, де структура коду будується навколо функціональності (features), а не навколо технічних шарів (наприклад, «components», «utils», «pages»).
Ідея: розділити проєкт за змістом (бізнес-функціями), а не просто за типами файлів.
Головна мета FSD
Зробити проєкт масштабованим і зрозумілим: щоб під час росту коду ти завжди знав, куди покласти новий модуль, і щоб зміна однієї фічі не ламала решту.
Основні рівні (Layers)
FSD ділить проєкт на шари, кожен з яких має свою зону відповідальності. Типова структура виглядає так:
src/
app/ → the root application (initialization, providers, routing)
processes/ → cross-cutting business processes (for example: authentication, checkout)
pages/ → pages (profile page, cart page, etc.)
features/ → individual features (login, filtering, like, comments)
entities/ → business entities (User, Product, Order, Post)
shared/ → reusable utilities, UI, helpers, API, hooksРолі шарів
| Шар | Що робить | Приклад |
|---|---|---|
| shared/ | Загальні перевикористовувані частини | UI-бібліотека, utils, hooks |
| entities/ | Моделі предметної області | User, Product, Post |
| features/ | Конкретні користувацькі дії | Лайк поста, додавання в кошик |
| pages/ | Збирання фіч і сутностей у конкретну сторінку | ProductPage, ProfilePage |
| processes/ | Наскрізні процеси між сторінками | Авторизація, оформлення замовлення |
| app/ | Точка входу, роутер, глобальні провайдери | App.tsx, Providers, ErrorBoundary |
Принцип «знизу вгору»
shared → entities → features → pages → processes → appНижчі рівні не знають про вищі. Наприклад:
- shared не повинен імпортувати нічого з features;
- features можуть використовувати entities і shared, але не навпаки.
Так зберігається спрямованість залежностей і чистота архітектури.
Структура всередині фічі
Кожна фіча (або сутність) - ізольований модуль, у якому є все, що їй потрібно:
features/
add-to-cart/
ui/
AddToCartButton.tsx
model/
store.ts
selectors.ts
lib/
formatPrice.ts
index.tsУ фічі є свої UI-компоненти, своя логіка, свої типи та стор. Це робить її незалежною і переносною.
Приклад на React / Next.js
src/
shared/
ui/
Button.tsx
Input.tsx
lib/
formatDate.ts
entities/
user/
model/
types.ts
store.ts
ui/
UserAvatar.tsx
features/
login/
ui/LoginForm.tsx
model/store.ts
pages/
login/
index.tsx
ui/LoginPage.tsx
app/
providers/
RouterProvider.tsx
StoreProvider.tsx
index.tsxПереваги Feature-Sliced Design
| Перевага | Опис |
|---|---|
| Модульність | Кожен блок ізольований, легко змінювати або видаляти |
| Масштабованість | Можна додавати нові фічі без хаосу |
| Прозорість | Легко зрозуміти, де лежить бізнес-логіка |
| Контроль залежностей | Мінімум «спагеті-імпортів» |
| Сумісність з Atomic Design | У shared/ui можна зберігати атоми, молекули й організми |
| Інтегрується з будь-яким стеком | Next.js, React, Redux, Zustand, RTK Query тощо |
Приклад із реального світу
Замість хаотичної структури на кшталт:
components/
hooks/
utils/
pages/FSD пропонує:
shared/
entities/
features/
pages/Тепер, коли ти додаєш нову можливість, ти не думаєш:
«Це компонент чи хук?»
а думаєш:
«Це фіча (дія) чи сутність (об'єкт)?»
Сучасні практики в FSD
- Використовувати бар'єри імпортів (наприклад, eslint-plugin-boundaries)
- Експортувати назовні лише index.ts (public API)
- Декомпозувати UI за Atomic Design усередині shared/ui
- Розділяти логіку і представлення (model, ui, lib, api)
Підсумок
| Що | Опис |
|---|---|
| Ідея | Структурувати фронтенд за бізнес-функціями, а не за типами файлів |
| Основні шари | shared → entities → features → pages → processes → app |
| Мета | Масштабованість, модульність, зрозумілість |
| Основна одиниця | Feature (фіча) - ізольований модуль |
| Підходить для | Великих React / Next.js проєктів |
Формула FSD:
«Групуй код за змістом, а не за технологією. Нехай кожна фіча живе у своєму просторі й нічого не знає про інші».
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.