v2: UI приймає моделі chat-web-sdk напряму
Design decision (ADR-стиль). Статус: прийнято. Частково заміщує Межу даних — лише для v2 (
@webitel/ui-chats/v2); v1 і далі живе за тим рішенням.
Контекст
v2 відмальовує історію повідомлень і поле введення активного чату (WS-50, Figma DES-730). Щоб показати статуси (відправлено / доставлено / прочитано), системні сповіщення та авторів, UI потрібні саме ті дані, що вже є в бекенд-моделях: members, readStates (горизонти deliveredUpToSeq / readUpToSeq), seq, system, images / documents. Власний контракт ui-chats дзеркалив би їх 1:1, а адаптер лише перекладав би поле в поле.
Рішення
v2 приймає plain-моделі chat-web-sdk як вхід:
thread: ThreadModelmessages: MessageModel[]— і поточна сесія, і історія попередніх.
Тільки import type — runtime-залежності від SDK немає, тож @webitel/chat-web-sdk лишається optional peerDependency (peer-и задаються на весь пакет, не на subpath; v1-споживачам SDK не потрібен). Споживачі ./v2 мають SDK і так — ним живе їхній store. Власного v2-контракту і v2-адаптера немає. Похідні дані (статус повідомлення, автор, розділювачі за датою) v2 обчислює сам.
Класи IThread / IMessage структурно задовольняють ці типи, тож застосунок передає свій store як є. Але UI не викликає їхніх методів — пункт 3 «Межі даних» (поведінковим сутностям не місце в презентації) залишається в силі.
Розглянуті варіанти
- Власний v2-контракт + адаптер (шлях v1). Відкинуто: дзеркальні типи без нової інформації, подвійний синк при кожній зміні бекенду, а UI все одно мусить знати семантику
readStates/seq, щоб показати статус. - Типи напряму з
@webitel/api-services/gen/models. Відкинуто: SDK — офіційна точка входу для цих моделей (ThreadModelзвужуєidдо обов'язкового); тягнути orval-імена в UI гірше.
Наслідки
- Зміни бекенд-моделей тепер напряму зачіпають шаблони v2 — свідома ціна за відсутність шару маппінгу.
- Реліз v2 зчеплений з версією
chat-web-sdk(semver, поза CalVer-локстепом). - Фікстури для тестів — plain-об'єкти
MessageModel/ThreadModel, без фабрик з config.