Уведомления (toast / notifications)

Потребность: единый слой уведомлений (toast) с фасадом, типизацией и связью с обработкой ошибок и брендингом, чтобы не зависеть от конкретной библиотеки и единообразно показывать сообщения пользователю.

Обоснование

В enterprise и Low-Code платформах уведомления пользователю (успех, ошибка, предупреждение) идут через единый API: это позволяет подменять реализацию (библиотеку), применять общие политики (лимит, группировка) и связывать с глобальным обработчиком ошибок. OutSystems, Mendix и аналоги предоставляют централизованные сообщения и тосты. Риск при отсутствии фасада: жёсткая привязка к vue-sonner по всему коду, разное поведение при отображении ошибок и сложность смены библиотеки или темизации.

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

• Реализация: vue-sonner — тосты выводятся через toast.success, toast.error, toast.info, toast.warning из пакета.
• Использование: прямые вызовы в компонентах, виджетах и feature stores; строки сообщений и опции передаются каждый раз на месте вызова.
• Стили: подключение vue-sonner/style.css в App.vue; глобальный компонент <Toaster /> в layout.
• Нет абстракции «слой уведомлений»: смена библиотеки (например, на другую тост-систему) потребует замены вызовов по всему коду. Нет единого контракта типов (success, error, info, warning, loading, promise) и нет централизованной очереди/политики (лимит одновременных тостов, группировка, TTL).

Чего не хватает

1. Абстракция над реализацией: один API приложения (например, notifications.success(message, options)), внутри — вызов vue-sonner или другой библиотеки. Замена реализации в одном месте.
2. Типизация и контракт: тип сообщения (success, error, info, warning, loading, promise), опции (description, duration, id, onAction, cancel), при необходимости — кастомный контент (компонент/slot).
3. Связь с обработкой ошибок: глобальный обработчик ошибок может вызывать notifications.error(userMessage); тогда все уведомления об ошибках идут через один слой и можно единообразно менять текст и поведение.
4. Связь с брендингом/темами: тосты должны учитывать текущую тему и при необходимости бренд; это проще делать через один компонент/конфиг тостера.
5. Опционально: очередь, лимит одновременных тостов, группировка по типу или по ключу (например, «одна тоста „сохранено“ на действие»).

Рекомендуемое направление

Модуль уведомлений (в @endge/ui-vue или отдельный @endge/notifications)

• Фасад: notify.success(msg, options?), notify.error(msg, options?), notify.info, notify.warning, при необходимости notify.promise(promise, messages) и notify.loading(msg).
• Реализация по умолчанию: обёртка над vue-sonner; регистрация через Vue Module Endge.vue при инициализации приложения, глобальный Toaster рендерится один раз.
• Опции: duration, description, id, onAction, cancel — по контракту модуля; при смене библиотеки меняется только маппинг этих опций.
• Типы: интерфейс NotificationOptions и тип NotificationType в одном месте; все вызовы в приложении и в пакетах идут через этот фасад.
• Ошибки: модуль обработки ошибок вызывает notify.error(...) для пользовательских сообщений; уведомления не содержат стек и технические детали, только то, что разрешено показывать пользователю.

Где размещать

• Если уведомления нужны только в приложениях на Vue и тесно связаны с EndgeShell/layout — логично в @endge/ui-vue (composable + плагин + обёртка над sonner).
• Если планируется использование в не-Vue окружениях или хочется жёстко отделить «логику уведомлений» от «Vue-виджета» — выделить пакет @endge/notifications с контрактом и адаптером для vue-sonner в @endge/ui-vue.

Брендинг и темы

• Конфигурация Toaster (позиция, стили, лимит) может брать текущий бренд из useBranding() или из конфига приложения; модуль уведомлений получает эту конфигурацию при инициализации и передаёт в рендер тостов.

Практические шаги

1. Ввести фасад уведомлений (функции notify.*) и типы опций в одном модуле.
2. Реализовать фасад поверх vue-sonner; подключить в плагине/инициализации приложения.
3. Постепенно заменить прямые вызовы toast.* на notify.* в коде приложения и пакетов.
4. Подключить вызов notify.error из централизованного обработчика ошибок для пользовательских сообщений.
5. При необходимости добавить политику очереди (лимит, группировка) внутри фасада.

Риски и ограничения

• Замена прямых вызовов toast.* на фасад потребует прохода по коду; делать постепенно. Связь с Error_Handling: обработчик ошибок должен вызывать фасад уведомлений для пользовательских сообщений, а не дублировать логику отображения.

Вывод

• Имеет смысл выделить единый слой уведомлений (фасад + типы + обёртка над vue-sonner) для замены реализации в одном месте и единообразной связи с обработкой ошибок и брендингом.
• Размещение: в @endge/ui-vue как часть Vue-инфраструктуры или отдельный пакет @endge/notifications с адаптером в vue — по решению о границах пакетов.