Feature-Sliced Design
Що таке Feature-Sliced Design (FSD)
Feature-Sliced Design (FSD) - це архітектурний підхід до організації фронтенд-проєкту, де структура коду будується навколо функціональності (features), а не навколо технічних шарів (наприклад, «components», «utils», «pages»).
Ідея: розділити проєкт за змістом (бізнес-функціями), а не просто за типами файлів.
Головна мета FSD
Зробити проєкт масштабованим і зрозумілим: щоб під час росту коду ти завжди знав, куди покласти новий модуль, і щоб зміна однієї фічі не ламала решту.
Основні рівні (Layers)
FSD ділить проєкт на шари, кожен з яких має свою зону відповідальності. Типова структура виглядає так:
src/
app/ → кореневий застосунок (ініціалізація, провайдери, роутинг)
processes/ → наскрізні бізнес-процеси (наприклад: автентифікація, покупка)
pages/ → сторінки (сторінка профілю, кошика тощо)
features/ → окремі фічі (логін, фільтрація, лайк, коментарі)
entities/ → бізнес-сутності (User, Product, Order, Post)
shared/ → перевикористовувані утиліти, UI, хелпери, API, хукиРолі шарів
| Шар | Що робить | Приклад |
|---|---|---|
| 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: «Групуй код за змістом, а не за технологією. Нехай кожна фіча живе у своєму просторі й нічого не знає про інші».
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.