тоже вроде как взаимодействие с ui, но неужели нужно делать отдельный компонент и в нем вызывать этот снекбар

да, это и мои аргументы, но вдруг есть знания дедов, которые я упустила

Идеологически не стоит так делать

Фактически там в кишках это так и происходит.

а как надо идеологиески?

В этом плане я бы уповал на .https://www.python.org/dev/peps/pep-0020/#id2

А именно "явно лучше чем неявно"

а явно это как в данном случае?

Этот сервис нарушает SRP (Single Responsibility Principle)? Нет? Значит все ок.

(почему не нарушает? потому что SRP -  это о single reason to change, какая причина у данного  сервиса изменится? если логика авторизации изменилась)

Ну убрали ребята монтирование этого компонента в один момент - и ищи его потом

Плюс видеть что у тебя может появиться во вьюхе ИМХО лучше у себя на месте

на каком месте?

Ну типо смонтировать компонент повыше к корню приложения для отображения сообщений и проксировать к шине сообщений самой.

Но это больше кода.
Но зато видно будет

так зачем вообще этот компонент, если можно без него?

кинул гвард на роут – он там работает, убрал – не работает. зачем компонент создавать?

Просто для очевидности, наглядности.
Гуард он не совсем же для отрисовки чего либо создан, насколько мне известно

Привет!

По канонам ООП, все что представляет собой некую абстрактную сущность, которую можно представить в виде отдельного объекта, нужно в этот самый объект выделять и всю его логику работы инкапсулировать внутри, наружу прокидывая только внешний интерфейс взаимодействия с ним. Это и есть основная суть ООП, потом можем приписать наследование и полиморфизм, но сейчас нам это не интересно. Делается это с целью разбить все приложение на атомарные части, которые можно легко менять, абсолютно не трогая и не ломая все остальные такие же атомарные части. Ведь если внешний интерфейс не поменялся, то без разницы что ты меняла внутри - снаружи все работает также.
Делается это, как минимум, для переиспользования.
Упрощенно, ты копируешь файл в другой проект и все (имеется в виду логика этого объекта) работает также из коробки.
Ты импортишь этот компонент в этом же проекте, но в другом месте, вызываешь те же методы, что и в первом варианте (опять же, не берем полиморфизм и вариации использования) и получаешь из коробки переиспользование.
Вторая причина - меняешь в одном месте и результат автоматически меняется во всех местах переиспользования, если они есть.

То есть, ты заранее думаешь о том, что эта логика может быть переиспользована и будет дорабатываться/меняться.

Теперь, в твоем варианте, если тебе понадобится в другом гарде/части проекта/другом проекте повторить эту логику - это получится сделать без дублирования кода, просто вызовом метода или инстанцииорованием компонента или же придется продублировать код? (нарушим DRY, об этом по сути вторая причина).

То есть, если в твоем случае, это просто вызов метода и там нет никакой логики, кроме вызова, то все ок. Если там есть своя логика, отдельная от ответственности гарда (SRP, о котором упоминал Алексей), например, условие или проверка авторизации или т.п. то логично вынести ее в отдельную сущность (сейчас не говорю про компонент, сервис и т.д.), чтобы в будущем ее можно было переиспользовать и централизованно менять.

ого, Саша, спасибо за такой длинный ответ