Направление работ: Weblk Код раздела: 8.7.4 Архитектура и инфраструктура > Инициализация приложения Статус: черновик Ответственный: Рыженко И.С. Версия: 0.1 Обновлено: 22.05.26
Рефакторинг инициализации приложения (WebLk)
[Технический долг, приоритет: высокий]
1. Проблема
При старте кабинета партнера инициализация приложения не детерминирована и размазана по трем независимым модулям. Каждый из них создает собственное состояние инициализации и самостоятельно запрашивает данные у бекенда, не зная о действиях других.
Это приводит к двум классам проблем:
Проблема 1 — Дублирование запросов
-
initializeApp() вызывается минимум дважды при каждом старте
-
SignalR-подписки запускаются дважды
-
Бекенд получает дублирующие запросы (нагрузка без причины)
-
Пользователь видит лишние состояния загрузки
Проблема 2 — Частичная готовность данных
-
Пользователь попадает на защищенные страницы до того, как все необходимые данные загружены
-
Например: пользователь авторизован, но данные партнерской зоны еще не получены
-
Это порождает непредсказуемые ошибки в интерфейсе
2. Текущее состояние
При старте приложения одновременно запускаются три независимых потока инициализации:
Поток 1 — auth.global middleware
-
Проверяет cookie auth_token, при необходимости обновляет
-
Вызывает plugins/app-initializer.client.ts
-
Создает локальный initState #1
-
Вызывает initializeApp() → запрашивает пользователя у бека
-
Запускает SignalR subscribe
Поток 2 — страница integrations.vue
-
Создает собственный локальный initState #2 независимо от потока 1
-
В onMounted вызывает initializeApp() повторно
-
Повторно запрашивает данные партнерской зоны у бека
-
Самостоятельно запускает initializeCalendar()
Поток 3 — partner-zone-access.global.ts
-
Создает локальный initState #3
-
Проверяет состояние, которое не связано с основным плагином
-
Фактически смотрит в пустоту — не видит результатов потоков 1 и 2
3. Ожидаемый результат
После рефакторинга инициализация представляет собой единый линейный поток с одним глобальным статусом. Пользователь не попадает на защищенные страницы до тех пор, пока приложение не достигло состояния ready.
Состояния глобального статуса:
| Статус | Значение |
|---|---|
| loading | Приложение запускается, данные еще не получены |
| unauthenticated | Токен отсутствует или невалиден — пользователь не авторизован |
| needsPartnerRegistration | Пользователь авторизован, но партнерская зона не найдена |
| ready | Все данные получены, защищенные страницы доступны |
Ключевые изменения:
| Было | Стало |
|---|---|
| 3 независимых initState | 1 глобальный статус |
| Страницы сами инициализируются | Страницы только читают готовый статус |
| Пользователь попадает с частичными данными | Страница открывается только в ready |
| SignalR стартует дважды | SignalR стартует один раз |
| 2–3 дублирующих запроса к беку | Один запрос при старте |
4. Затронутые файлы и страницы
Файлы, требующие изменений:
-
plugins/app-initializer.client.ts
-
pages/partner-profile/tools/integrations.vue
-
pages/orders/calendar.vue
-
pages/orders/processing-group/index.vue
-
pages/requests/index.vue
-
middleware/partner-zone-access.global.ts
-
composables/useAppInitializer.ts
-
stores/global.ts
-
stores/auth.ts
Затронутые страницы:
-
/partner-profile
-
/orders
-
/orders/calendar
-
/orders/processing-group
-
/requests
Важно: UI страниц не переделывается. Изменяется только логика получения данных при инициализации.
5. Риски
| Зона | Риск | Митигация |
|---|---|---|
| Красная | integrations.vue и partner-zone-access перестанут работать без адаптации под новый статус | Включены в список файлов к изменению, проработаны до старта |
| Красная | Скрытые вызовы initializeApp() в других частях кода | Поиск по всей кодовой базе до старта работ |
| Желтая | Компоненты с неявной зависимостью на поэтапную загрузку данных | Проверка на тестовом стенде перед выкаткой на прод |
| Желтая | watch на currentPartnerZoneId — поведение после рефакторинга | Согласовать с разработчиком: остается или переезжает в инициализатор |
| Зеленая | Бизнес-логика заказов, платежей, отчетов | Не затрагивается |
6. Оценка работ
| Этап | Оценка |
|---|---|
| Написать новый модуль инициализации | |
| Убрать старую логику из трех модулей | |
| Проверить все затронутые модули | |
| Тестирование и фиксы на тест-стенде | |
| Итого: |
7. Критерии приемки
-
initializeApp() и useAppInitializer() вызываются ровно один раз при старте
-
SignalR запускается один раз
-
Защищенные страницы недоступны до достижения статуса ready
-
Sentry не фиксирует новых ошибок инициализации после релиза
-
Основные сценарии (логин, смена зоны, защищенные страницы) проверены на тестовом стенде
8. Вне скоупа этой задачи
-
Полный рефакторинг авторизации (отдельная задача, будет проще после этой)
-
Переделка UI страниц
-
Изменения на бекенде