NODEDC_DESIGN_GUIDELINE/docs/ADOPTION.md

Подключение приложений

Текущее состояние

Первый этап не меняет существующие приложения. Репозиторий фиксирует baseline и создаёт пакетный контракт. Это позволяет продолжать текущую разработку без одномоментной переделки Engine, Ops, BIM, CMS, SEO и Launcher.

Рекомендуемый порядок

1. Catalog validation

Сначала компоненты проверяются как самостоятельная система в dark/light и нескольких accent. До этого они не объявляются заменой production-кода.

2. Launcher/Hub pilot

Первый consumer — Launcher/Hub как основной visual reference. Подключение выполняется по одному вертикальному набору:

• tokens/theme;
• Button/IconButton;
• Dropdown/Select;
• Window/Confirmation;
• AppHeader.
• ApplicationShell/ApplicationPanel;
• useApplicationWorkspace;
• Icon/IconButton.

Локальные реализации удаляются только после функционального и визуального сравнения.

3. CMS и SEO

Используют те же компоненты и механику окон. CMS подключает DOM-layer, SEO — React-layer. Первым общим admin pattern подключается MediaSourceField/createMediaSourceController; storage API остаётся в приложении. Цветовые различия оформляются theme overrides.

4. Engine

Сначала библиотека заменяет компоненты только в уже новом Environment Settings и NDC Agent Inspector. Затем остальные инспекторы переводятся на Inspector/ControlRow постепенно. Legacy UI не переносится в библиотеку и не используется как reference.

5. Task Manager / Ops

Подключение начинается с floating-layer и modal primitives, где уже сформулирован канон. Массовая замена Plane UI не выполняется одним изменением.

6. BIM Viewer

Подключает tokens/styles и @nodedc/ui-dom. React в BIM ради дизайн-системы не добавляется.

Новые приложения

Новый React-проект начинает с ApplicationShell:

• установить опубликованные NODE.DC UI packages;
• выбрать theme и accent;
• передать фиксированный AppHeader, stage, navigation и content;
• управлять shell через useApplicationWorkspace, а не набор локально связанных boolean;
• передавать storage/upload в MediaSourceField как adapter callback;
• использовать Window/Dropdown и канонический Icon вместо локальных реализаций;
• проверять registry перед созданием локального control;
• хранить доменные компоненты у себя.

Нижняя service rail добавляется только продуктам с витриной сервисов. В обычном оконном приложении она отсутствует.

Adoption matrix

Приложение	Текущий источник	Целевой adapter	Первый набор
Launcher/Hub	React/local shared	React	header, button, dropdown, window
SEO	React/local overrides	React	theme, window, field, select
CMS	Vanilla DOM	DOM	theme, header, modal, select
Engine	React/mixed generations	React	new inspector and environment settings only
Ops	React/Plane packages	React	floating behavior and modal primitives
BIM Viewer	Vanilla JS	DOM	tokens, glass select, settings surfaces

Не делать

• не переписывать все приложения одновременно;
• не копировать packages/ui-react/src в consumer;
• не поддерживать отдельную тему путём fork компонента;
• не использовать legacy Engine inspector как промежуточный канон;
• не удалять production local component до проверки package replacement.