это уже следующий уровень... мы пока в интерсептор пытаемся засунуть поток и подвесить все приложение ради непонятно чего)))

хорошие frontend’ы тихо без участия пользователя получают новую пару

и про это пока забудем)) давай еще раз - если токен не валиден, у нас есть готовая цепочка действий и прописанная логика как получить валидный. Верно?

Согласен, я и не говорил, что нужно участие пользователя ))

да

состояние "токен не валидный" === "токена нет". Ты придумываешь лишние заморочки на пустом месте, пытаясь оптимизировать число запросов к беку за счет вероятности поломать логику фронта и повесить приложение в состояние ожидания от обзервера. При том что ситуация того не требует

Что касается "хороший фронт поднимает авторизацию без участия пользователя", то это вторая стадия)) Помимо токена сеанса (авторизации) - мы генерим длинный (ну допустим месяц, в отличие от короткого с 2 минутами жизни)  токен сессии. В базу кладем фингерпринт устройства и длинный токен. В короткий в пейлоад запихиваем доппараметром фингерпринт. Короткий токен храним где угодно, хоть в локалстораже, хоть в куках.

ребятки, хочу создать отдельный модуль для "глупых" компонентов. Как думаете насколько это целесообразно, ваши аргументы?

Dumb.module.ts

Пользователь залогинился, получил короткий токен, длинный записан в базу (экспайр и слепок устройства). Сеанс работает, при каждом запросе мы сверяем слепок из короткого с тем что записан для длинного в базе. Если совпадает - ок, пропускаем короткий, рефрешим его и экспайр длинного. Сеанс завершен, пользователь свалил. Прошло три дня, он открывает страницу. Бек получает протухший короткий токен. Смотрит слепок в базе, сверяет. Если экспайр длинного не протух - восстанавливает короткий и пользователь авторизован без ввода логина. Если длинный протух, если пришел слепок другого устройства - длинный дискредитирован, удаляем из базы и требуем принудительного логина

мы по этому живем https://tools.ietf.org/html/rfc7519

Получится тоже самое что shared modules. Лучше такого избегать и следовать принципу "один компонент = один модуль"

оказывается, словами сложно изложить)) но думаю суть донес

Если эти компоненты нужны в нескольких модулях, то очень целесообразно

да, как минимум в двух модулях буду использовать эти компоненты. Спасибо

спасибо за мысль, имеет место быть

да, словами, сложно, хорошо, хоть поняли проблему оптимизация кол-ва запросов 🙂

а есть rfc или что-нибудь подобное по этому?

Вы же в не сможете использовать один созданный компонент в разных модулях, если не запихнёте его в отдельный модуль. Принцип angular такой. А вот уже отдельный модуль можно подключать в скольки угодно модулях.

не уверен, что в данной ситуации их вообще рационально оптимизировать))) хотя может у вас это штатная ситуация "запрос на защищенную страницу при негарантированном наличии токена" и она требует отдельной логики. На превый взгляд - это уже чистой воды ловля тараканов (одного) на футбольном поле)))