SILVER
/
NODEDC_TASKMANAGER
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_TASKMANAGER/docs_prod/1_STEP_cross-project-task-r.../11_STEP_external-contours-d...

7.8 KiB
Raw Permalink Blame History

Шаг 11. Единый shell карточки внешнего контура

Зачем нужен этот шаг

Сейчас карточка деталей во Внешних контурах решает прикладную задачу, но UX-паттерн у нее другой, чем во Внутреннем контуре.

Из-за этого:

  • у пользователя ломается ожидаемая логика открытия карточки
  • верхний action-bar живет по другим правилам
  • повторяется UI-логика, которая уже есть у стандартного peek-shell
  • дальнейшее развитие Внешних контуров начинает расходиться с остальным продуктом

Следующий шаг должен выровнять не данные, а каркас взаимодействия.

Целевой результат

По клику на карточку во Внешних контурах пользователь получает тот же класс панели, что и во Внутреннем контуре:

  • закрытие просмотра
  • полноэкранный режим
  • переключение макета
  • подписка или отписка
  • копирование ссылки
  • меню дополнительных действий

При этом тело карточки остается отдельным и специфичным для Внешних контуров.

Что обязательно сохраняем

Карточка внешнего контура не должна деградировать до обычной карточки Issue.

Нужно сохранить:

  • source-side режим без обязательного membership в target project
  • блок Маршрутизация
  • зеркалирование комментариев, вложений и activity
  • внешний lifecycle Принять / Отклонить / Ответ во внешний контур
  • правила доступа, отличающиеся от обычного внутреннего рабочего элемента

Иначе мы потеряем главный смысл модуля.

Что меняем

Меняем только shell и верхний UX-паттерн:

  • каркас панели
  • поведение открытия и закрытия
  • поведение полноэкранного режима
  • верхний блок действий
  • раскладку заголовка и служебных controls

То есть цель шага — унификация оболочки, а не унификация доменной модели.

Что не входит

В этот шаг не входят:

  • новые колонки Исходящие / Входящие
  • drag-and-drop
  • пользовательские кастомные представления
  • перенос всех операций внешнего контура на стандартные issue services
  • удаление запроса как обязательное действие из header action set

Архитектурный принцип

Нельзя копировать целиком реализацию peek overview внутреннего контура и натягивать ее поверх внешней сущности.

Правильный путь:

  • переиспользовать shell-контракт
  • переиспользовать header action pattern
  • оставить внешний data-flow отдельным
  • оставить body карточки отдельным

То есть нужен не clone существующей карточки, а повторное использование общего слоя представления.

Рекомендуемое разбиение реализации

1. Общий слой shell

Нужен общий контракт боковой карточки, который умеет:

  • sidebar-режим
  • full-screen режим
  • общий overlay и поведение закрытия
  • общий header slot
  • общий body slot

2. Отдельный adapter для Внешних контуров

Нужен внешний adapter, который подает в shell:

  • title
  • служебные действия
  • доступные действия меню
  • состояние source-only или target-access
  • body контент внешнего контура

3. Отдельный action set

Нельзя слепо использовать меню обычной задачи.

Нужно отдельное правило доступных действий для внешнего контура:

  • закрыть
  • fullscreen
  • layout toggle
  • subscribe/unsubscribe
  • copy link
  • ...

При этом ... для внешнего контура должен быть ограничен собственным набором действий и не обязан повторять delete-flow внутреннего рабочего элемента.

Риски, которые надо избежать

1. Смешение доменных сущностей

Если внешний запрос начать вести как обычный Issue, то быстро сломаются:

  • source-side права
  • логика bridge
  • роутинг действий Принять / Отклонить
  • зеркальная история

2. Дублирование shell-кода

Если сделать второй независимый peek-shell только для Внешних контуров, то дальше появятся:

  • рассинхрон верхних action-bar
  • повторная поддержка полноэкранного режима
  • повторная поддержка keyboard и close behavior

3. Преждевременная универсальная платформа

Не нужно ради одного шага строить абстрактный UI-framework на все возможные будущие сущности.

Нужен только тот общий контракт, который уже доказан двумя режимами:

  • Внутренний контур
  • Внешние контуры

Критерий приемки

  • карточка Внешних контуров открывается по тому же UX-паттерну, что и во Внутреннем контуре
  • верхняя панель действий выглядит и ведет себя единообразно
  • body карточки остается внешнеконтурным
  • source-only сценарий не ломается
  • без прямого доступа в target project пользователь все равно видит рабочую карточку

Зависимость следующего шага

Этот шаг желательно сделать до полной двусторонней доски.

Причина простая:

  • доска Исходящие / Входящие увеличит число точек входа в карточку
  • если shell не унифицирован заранее, новый board-layer закрепит текущую раздвоенную архитектуру

Следующий связанный шаг описан в: