Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «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/ → кореневий застосунок (ініціалізація, провайдери, роутинг) 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 | ## Принцип «знизу вгору» ```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:** > «Групуй код за змістом, а не за технологією. > Нехай кожна фіча живе у своєму просторі й нічого не знає про інші».Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.