154 lines
10 KiB
Plaintext
154 lines
10 KiB
Plaintext
ФЛОУ
|
||
- после создания компонента, заменить шаблонный коментарий документа на реальный.
|
||
|
||
|
||
Проблема, неочевидность слоев (наследие FSD)
|
||
|
||
|
||
Архитектурные слои проекта
|
||
Каждый нижний слой не знает о существовании верхних. Импорты идут только сверху вниз.
|
||
pages → layouts → screens → widgets → features → entities → shared
|
||
---
|
||
1. Pages (pages/)
|
||
Точка входа маршрута. Только связывает layout и screen.
|
||
Правила:
|
||
- Никакой логики, стилей, разметки кроме композиции
|
||
- Один page = один layout + один screen
|
||
Пример:
|
||
// pages/knv-new.js
|
||
import { KnvScreen } from 'src/screens/knv'
|
||
import { MainLayout } from 'src/layouts/main'
|
||
const KnvNewPage = () => (
|
||
<MainLayout>
|
||
<KnvScreen />
|
||
</MainLayout>
|
||
)
|
||
---
|
||
2. Layouts (src/layouts/)
|
||
Каркас страницы — общие элементы, которые одинаковы на всех страницах в рамках этого layout.
|
||
Содержит в ui/: header, footer, sidebar — дочерние компоненты, которые привязаны к layout и не переиспользуются отдельно.
|
||
Критерий: компонент одинаков на всех страницах, использующих этот layout? → layouts/{name}/ui/
|
||
Пример:
|
||
src/layouts/main/
|
||
├── main.layout.tsx # <Header /> + children + <Footer />
|
||
├── ui/
|
||
│ ├── header/ # всегда одинаковый на всех страницах
|
||
│ └── footer/ # всегда одинаковый на всех страницах
|
||
---
|
||
3. Screens (src/screens/)
|
||
Контент конкретной страницы. Собирает свои секции и переиспользуемые widgets/features/entities.
|
||
Содержит в ui/: блоки, которые существуют только на этой странице и не переиспользуются.
|
||
Критерий: компонент используется только на одной странице? → screens/{name}/ui/
|
||
Пример:
|
||
src/screens/knv/
|
||
├── knv.screen.tsx
|
||
├── ui/
|
||
│ ├── hero-section/ # hero только на главной КНВ
|
||
│ ├── products-section/ # секция препаратов только на главной
|
||
│ ├── diseases-section/ # секция заболеваний только на главной
|
||
│ └── doctor-section/ # секция врачей только на главной
|
||
Каждая секция внутри может использовать shared/ui компоненты:
|
||
// screens/knv/ui/products-section/products-section.widget.tsx
|
||
import { Carousel } from 'src/shared/ui/carousel'
|
||
import { ProductCard } from './ui/product-card' // локальный, пока не переиспользуется
|
||
Когда локальный компонент начинает использоваться на 2+ страницах — выносим в entities/ или shared/ui.
|
||
---
|
||
4. Widgets (src/widgets/)
|
||
Составные блоки с данными/логикой, которые переиспользуются на 2+ страницах.
|
||
Критерий: блок с бизнес-логикой + данными используется на нескольких страницах? → widgets/
|
||
Пример: Слайдер «Популярные препараты» с загрузкой данных из API, который показывается и на главной, и на странице заболевания, и в каталоге:
|
||
src/widgets/
|
||
├── popular-products-slider/
|
||
│ ├── popular-products-slider.widget.tsx # Carousel + ProductCard + useProducts()
|
||
│ ├── hooks/
|
||
│ │ └── use-products.hook.ts # запрос данных
|
||
Не widget: секция «Подобрать врача» которая есть только на главной → screens/knv/ui/
|
||
---
|
||
5. Features (src/features/)
|
||
Пользовательское действие или интерактивный сценарий. Содержит бизнес-логику взаимодействия.
|
||
Критерий: это действие пользователя (отправить форму, авторизоваться, добавить в корзину)? → features/
|
||
Примеры:
|
||
src/features/
|
||
├── auth/ # авторизация (форма + логика + стор)
|
||
│ ├── auth.feature.tsx
|
||
│ ├── hooks/
|
||
│ │ └── use-auth.hook.ts
|
||
│ └── stores/
|
||
│ └── auth.store.ts
|
||
│
|
||
├── order-drug/ # заказ препарата (кнопка + модалка + API)
|
||
│ ├── order-drug.feature.tsx
|
||
│ └── hooks/
|
||
│ └── use-order.hook.ts
|
||
Не feature: отображение карточки препарата без взаимодействия → entities/ или shared/ui
|
||
---
|
||
6. Entities (src/entities/)
|
||
Бизнес-сущность с её отображением и типами. Привязана к домену (препарат, заболевание, врач, пользователь).
|
||
Критерий: это представление бизнес-объекта, которое переиспользуется в разных контекстах? → entities/
|
||
Примеры:
|
||
src/entities/
|
||
├── product/ # Препарат
|
||
│ ├── ui/
|
||
│ │ └── product-card/ # карточка препарата (каталог, слайдеры, поиск)
|
||
│ ├── types/
|
||
│ │ └── product.type.ts # { id, name, mnn, indication }
|
||
│ └── index.ts
|
||
│
|
||
├── disease/ # Заболевание
|
||
│ ├── ui/
|
||
│ │ └── disease-card/
|
||
│ ├── types/
|
||
│ │ └── disease.type.ts
|
||
│ └── index.ts
|
||
Отличие от shared/ui: entity-компонент знает о бизнес-домене (принимает Product, а не абстрактные пропсы). shared/ui Button не знает ничего о бизнесе.
|
||
---
|
||
7. Shared (src/shared/)
|
||
Переиспользуемые компоненты, утилиты, стили без бизнес-логики.
|
||
Критерий: компонент не знает о бизнес-домене, работает с абстрактными данными? → shared/
|
||
src/shared/
|
||
├── ui/ # UI-компоненты
|
||
│ ├── carousel/ # принимает children, не знает о препаратах
|
||
│ ├── container/
|
||
│ ├── section/
|
||
│ └── icon-svg/
|
||
├── styles/ # CSS-переменные, media
|
||
│ ├── variables.css
|
||
│ └── media.css
|
||
├── sprites/ # SVG-спрайты
|
||
└── lib/ # утилиты, хелперы
|
||
---
|
||
Сводная таблица принятия решений
|
||
Вопрос Да → Нет ↓
|
||
Это точка входа маршрута? pages/ ↓
|
||
Одинаков на всех страницах layout? layouts/{name}/ui/ ↓
|
||
Используется только на одной странице? screens/{name}/ui/ ↓
|
||
Составной блок с данными на 2+ страницах? widgets/ ↓
|
||
Это действие пользователя с логикой? features/ ↓
|
||
Привязан к бизнес-сущности? entities/ ↓
|
||
Абстрактный UI без бизнес-логики? shared/ui/ —
|
||
|
||
|
||
И еще размышлений
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Что у нас по факту
|
||
Мы взяли FSD и добавили:
|
||
- Слой Layouts — каркас страницы
|
||
- Слой Screens — контент страницы с локальными компонентами
|
||
- Правило scope — компонент живёт максимально близко к месту использования, и поднимается на уровень выше только при переиспользовании
|
||
Это не FSD в чистом виде. Но и не что-то принципиально новое.
|
||
Существующие названия
|
||
Feature-Sliced Design (FSD) — то от чего отталкиваемся, но расходимся в деталях.
|
||
Screaming Architecture (Robert C. Martin) — структура проекта "кричит" о том, что он делает. Открываешь screens/knv/ui/ — видишь КНВ. Открываешь widgets/ — видишь глобальное. Это близко к нашему подходу.
|
||
Colocation Principle — держи код рядом с тем, где он используется. Именно этот принцип отличает нас от FSD: page-specific компоненты лежат внутри screen, а не в глобальном widgets/.
|
||
Как назвать
|
||
Я бы не стал придумывать новое название. Это:
|
||
> FSD с принципом колокации (FSD + Colocation)
|
||
Или проще — адаптированный FSD. Суть отличия укладывается в одно правило:
|
||
> Компонент живёт на самом низком уровне, где он используется. Поднимается выше только при переиспользовании на 2+ страницах.
|
||
Если хочется краткое название для внутренней документации — можно SLD (Scoped Layer Design), подчёркивая что каждый компонент привязан к scope (shared → entity → feature → widget → screen → layout → page).
|