1. Я пишу обычное веб-приложение, обрабатывающее запросы на страницы на бэке, где на основе данных в БД я генерирую HTML
1.1. В этом случае при запросе в авторизованную зону без куки на бэкенде я передам управление контроллеру, который вернет HTML с попапом логина.
1.2. На всех страницах у меня будет генерироваться NavBar, со ссылкой на /top-up. При запросе на эту страницу вернется HTML с попапом пополнения счета.
1.3. Так же как и в предыдущих случаях будет работать страница /premium.
1.3.1. При недостаточном балансе пользователь будет отправлен на страницу /top-up, а после пополнения обратно на страницу /premium. Причем это «обратно» может быть следующий переход в history, т.к. на /top-up мы пришли с параметром ?redirectUrl. Или это может вызов history.back(), чтобы вернуть пользователя назад по браузерной истории (сомнительно, но возможно).
2. Потом я решаю улучшить UX и пишу собственный обработчик переходов по ссылкам, который загружает HTML через AJAX и с эффектами вставляет в существующую страницу. Попапы обретают эффекты вылетания и убирания.
2.1. Я определенно использую history.back() при закрытии /top-up попапа и возвращения пользователя на /premium
2.2. Чтобы еще улучшить UX при запросе перехода на новую ссылку в AppController определяется не является ли новая страница попапом, и если так, то не буду выгружать DOM текущей страницы, а DOM попапа вставлю в специальный для этого элемент. В случае если там уже есть попап — перезатру его.
3. Потом я решаю вынести логику UI отдельно, логику системы отдельно. Так у меня получается, что есть веб-приложение из статических HTML, шаблонов, JS и стилей CSS. И отдельно API.
3.1. Я переношу логику контроллеров, которые отвечали за генерацию HTML на бэке на фронт.
3.2. PageController на фронте может выкинуть 401 (authentication required) и главный контроллер приложения AppController (а может и Router, но не на базе URL) решит показать системный попап аутентификации из своих шаблонов используя PopupPresenter, который уже решает все проблемы.
3.2.1. Предположим попап аутентификации ведет пользователя еще на один системный попап. Точнее выкидывает событие, которое ведет пользователя, например, на попап проверки на робота (вот такой мне придумался UX). Тогда тот же компонент используя PopupController показывает на месте попапа логина показывает попап капчи.
3.2.2. Когда логика попапа капчи отработала успешно, она кидает событие «я все», AppController проверяет стэк попапов и показывает попап login.
3.2.3. Попап login переинциализируется, подтягивает данные о капче и показывает, что человек не робот. Когда пройдена проверка credentials попап кидает событие «я все» и AppController через PageController пытается загрузить целевую страницу, которая текущая в Router.
3.3. Потом я решаю показывать промо-попапы на некоторых страницах. Я пишу PromotionsController, который отрабатывается к контексте иниализации страницы и подгружая какие-то данные из API решает показать промо-попап. Он использует PopupPresenter для отображения промо-попапа.
3.3.1. PromotionsController подписывается на событие промо-попапа «я все» и возможно решает показать еще один попап. Всю логику стэков промо-попапов он берет на себя.
3.3.2. PromotionsController не инициализируется до инициализации страниц. Значит если при запросе на страницу было 401, то AppController показывает попап login, страница не проинициализирована, PromotionsController не сует свои попапы.
3.3.3. Если инициализация страницы асинхронна и пользователь может взаимодействовать со страницей в момент инициализации PromotionsController, то необходимо предусмотреть интерфейс остановки инициализации, т.к. при некоторых действия пользователя (клики по ссылкам) страница может выгружаться.