Feature-sliced design (FSD). обов'язкова архітектура фронтенду для знання

Feature-Sliced Design (FSD) — це архітектурна методологія для фронтенд-додатків. Простими словами, це набір правил і конвенцій для організації коду. Головна мета методології — зробити проект зрозумілим і структурованим в умовах регулярних змін бізнес-вимог.

#Основні концепції FSD

1. Розділення шарів (slices)

• App: налаштування додатку, глобальні провайдери, маршрутизація.
• Pages: сторінки додатку з конкретним інтерфейсом, маршрутами та контейнерами.
• Features: окремі функції для користувачів (наприклад, "додати продукт до кошика", "аутентифікація").
• Entities: модулі, що описують і містять логіку "сущностей" домену (Користувач, Продукт, Замовлення тощо).
• Shared: загальні бібліотеки, утиліти, повторно використовувані компоненти (кнопки, іконки, функції валідації).

2. Групування коду за функціями

Замість того, щоб зберігати всі компоненти в одній папці components/, всі стилі в styles/ тощо, FSD пропонує зберігати весь код, пов'язаний з функціональністю (UI компоненти, логіка, стилі, тести) в одній функції. Це підвищує кохезію (цілісність) і спрощує знаходження потрібних файлів.

3. Чіткі межі відповідальності

Кожен шар відповідає за свій набір завдань. Наприклад, зміни в функції зазвичай не впливають на інші функції, оскільки загальні інструменти живуть у shared/, а глобальні налаштування — в app/.

#Переваги FSD

1. Масштабованість

Коли в додатку з'являються нові функції або бізнес-сценарії, їх додають як окремі директорії та модулі, не впливаючи на структуру інших частин.

2. Спрощене обслуговування

Якщо потрібно зрозуміти конкретну функцію або внести зміни, розробник бачить всю логіку функції — від компонентів до стилів — в одному місці.

3. Модульність

Легко підключати або відключати конкретні функції, переміщати їх в інший проект або робити їх окремим пакетом.

4. Мінімізовані конфлікти в команді

Розробники можуть працювати паралельно над різними функціями, не заважаючи один одному.

#Приклад структури

[Приклад 1]

[Приклад 2]

**[Приклад 3]**app

pages

features

entities

shared

home

add-to-cart

auth

user

product

ui

lib

config

У цих прикладах:

• app/ містить глобальну ініціалізацію та конфігурацію додатку.
• pages/ — окремі сторінки (маршрути).
• features/ — набір функцій (кожна функція містить все необхідне для її роботи: UI, бізнес-логіку тощо).
• entities/ — опис моделей (Користувач, Продукт тощо) та їх поведінки.
• shared/ — повторно використовувані компоненти, утиліти та конфігурації.

#Рекомендації до застосування

• Починайте з малого: не потрібно одразу впроваджувати всі шари, якщо у вас маленький додаток. Додавайте шари в міру зростання проекту.
• Чітко визначайте межі функцій: функція повинна вирішувати одне конкретне завдання (наприклад, "управління профілем користувача" або "додати продукт до кошика").
• Використовуйте найменування: якщо структура проекту стає складною, дотримуйтесь єдиних правил для найменування директорій і файлів, щоб уникнути плутанини.
• Дотримуйтесь принципів DRY, YAGNI та KISS: FSD — це лише схема організації коду. Вона не скасовує основні принципи написання чистого коду та продуманої архітектури.

#Джерело

Читати більше про Feature-Sliced Design тут.

#Зміст

Основні концепції FSDПереваги FSDПриклад структуриРекомендації до застосуванняДжерелоСхожі статті