так что , что есть правильно еще нет особого понимания)

this.$root.$emit(‘event-name’) и все. Но тут многие захейтят такие техники. Правда и обосновать не смогут почему это плохо)

Меня это сильно спасает. Но надо тоже аккуратно пользовать

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

Боюсь, без этих поломок все многократно усложнится. Да и какая изоляция компонентов если есть эмиты событий, пропсы, провайд/инжект и все такое. Не могут быть компоненты полностю изолированными друг от друга. Посмотрю что за решение. Не встречал. Спасибо

кстати тоже сталкивался с проблемой подъема события, конечно же был вариант во всей цепочке ловить/бросать событие наверх, но при определенной длине цепи, это абсурд и что тогда?

например, что если я хочу централизованную систему уведомлений и у меня есть компонент по типу snackbar из md, как мне из любого места в приложении вывести то, что я хочу? Создавать инстанс прямо на месте? А что если нужна очередь, чтобы из 5 разных мест уведомления не перекрыли друг друга? Логично создать 1 инстанс в 1 месте, передавать туда данные и в нем уже организовать очередь. И тут самый интересный вопрос, а как их передать, если компонент  может находится даже на другой ветке дерева?

Я видел решения по типу: давайте создадим плагин  $bus и заинжектим его, чтобы потом в него пушить событие и на него же подписываться? Зачем? Потому что в $root пушить плохо!

Я тоже по началу $bus сделал, а потом посидел, поковырял и подумал “какого черта?”. Зачем изобретать велосипед, плодить сущности если уже все есть. Живу с осознанием того что это “плохо” и мне пофиг)

посмотрел этот mitt. супер легковесный EventEmmiter из ноды, есть подозрение, что ведет это к тому же side vendor $bus, так а в чем прикол я не смог понять (несмышленый?), зачем нужно делать стороннюю реализацию, если есть готовая? Потому что это  нарушает концепцию или вызовет проблемы с производительностью? Если первое, то варианта два:
1) концепция не учитывает всех кейсов
2) изначальный вектор для решения задачи не тот.
И тогда если это второе, как на примере кейса с  уведомлениями, что выше, решить задачу, так, чтобы не возникало потребностей нарушать концепцию?

Мне это напомнило тему, когда я учился программировать мне говорили: "Никогда! НИКОГДА не используй goto!", а потом я столкнулся с яп, в котором в циклах есть break, но нет continue, а мне прям надо по условию скипать целые блоки кода. Мир больше никогда уже не смог бы стать прежним, пришлось использовать goto.

привет, в каком случае нужно делать запрос на получение данных в fetch, а в каком в mounted, я понимаю что один отрабатывает только на клиенте.... и вообще, зачем делать запрос в маунтед если есть фетч?

Дай тебе волю на заре молодости, и ты бы все время использовал goto, потому тебе и не давали к этому привыкать. Здесь так же. Я просто эмитю события осознанно, понимая плюсы и минусы. В моем случае плюсы перевешивают

хочешь делай запросы в маунтед, хочешь не делай. Никто же не заставляет)

ну я думал надо как то решить для себя что удобнее и правильнее

А зачем в наксте делать запросы в mounted?

вот у меня такой же вопрос) но многие делаеют

Ну просто я думал в nuxt пришли из за ssr

А так и обычного vue достаточно

не от большого ума) не вижу смысла когда запросы в маунтед нужны