Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Feature-Sliced Design». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Feature-Sliced Design (FSD)** - це архітектурний підхід до організації фронтенд-проєкту, де структура коду будується навколо функціональності (features), а не навколо технічних шарів. **Ключове:** ідея FSD - розділити проєкт за змістом (бізнес-функціями), а не просто за типами файлів.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## Що таке Feature-Sliced Design (FSD) **Feature-Sliced Design (FSD)** - це архітектурний підхід до організації фронтенд-проєкту, де структура коду будується **навколо функціональності (features)**, а не навколо технічних шарів (наприклад, «components», «utils», «pages»). Ідея: розділити проєкт **за змістом (бізнес-функціями)**, а не просто за типами файлів. --- ## Головна мета FSD > Зробити проєкт **масштабованим і зрозумілим**: щоб під час росту коду ти завжди знав, куди покласти новий модуль, і щоб зміна однієї фічі не ламала решту. --- ## Основні рівні (Layers) FSD ділить проєкт на шари, кожен з яких має свою зону відповідальності. Типова структура виглядає так: ```javascript 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 | --- ## Принцип «знизу вгору» ```javascript shared → entities → features → pages → processes → app ``` Нижчі рівні **не знають** про вищі. Наприклад: - shared не повинен імпортувати нічого з features; - features можуть використовувати entities і shared, але не навпаки. Так зберігається спрямованість залежностей і чистота архітектури. --- ## Структура всередині фічі Кожна фіча (або сутність) - ізольований модуль, у якому є все, що їй потрібно: ```javascript features/ add-to-cart/ ui/ AddToCartButton.tsx model/ store.ts selectors.ts lib/ formatPrice.ts index.ts ``` У фічі є **свої UI-компоненти**, **своя логіка**, **свої типи та стор**. Це робить її **незалежною і переносною**. --- ## Приклад на React / Next.js ```javascript 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 тощо | --- ## Приклад із реального світу Замість хаотичної структури на кшталт: ```javascript components/ hooks/ utils/ pages/ ``` FSD пропонує: ```javascript 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: > «Групуй код за змістом, а не за технологією. Нехай кожна фіча живе у своєму просторі й нічого не знає про інші».Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.