Хорошее решение импортировать store в каждый из компонентов на который

линки идут?

нормальное, на то он и стор, что он глобальный и к нему можно получить доступ откуда угодно

Не обязательно, можно в глобальный контекст вынести

Как? Можете ссылку на доку пожалуйста. Ато итак напрягаем тут отвечающих.

https://stackoverflow.com/questions/40896261/apply-global-variable-to-vuejs

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

Почему?

если не считать, что глобальные переменные - в принципе плохая практика по многим причинам, то это просто неудобно/бессмысленно: - если юзать с Options API, то стор может быть уже доступен через this.$store - если Composition API, то добраться до globalProperties дольше, чем трижды импортировать этот стор руками ну и автоматические импорты в IDE тоже никуда не делись, многие почему-то этим не пользуются

Почему это плохая практика?

неявность, любой можжет туда влезть, легко словить конфликт еще и доступ медленнее к такому но это мелочь

Нет, не медленнее :)

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

медленнее. Так как виртуалке нужно дольше идти по цепочке EnvronmentRecords

Референс просто каждый инстанс вью инжектится, одинаковая скорость будет

стоп стоп стоп давай проясним что ты имеешь ввиду речь идет о браузерных глоабльных переменных а не о globalProperties

я говорю про globalProperties

Ну понятно, лучше миллион импортов конечно в каждом божем компоненте, чем один раз в глобал вынести хелперы какие нибудь. А нюкст 3 ваще дебилы раз так сделали компосиблы глобальные

это автоимпорты а не глобальные перменные

эти импорты явные и сразу видно, откуда что берется, тем более, что любая современная IDE их пишет за тебя, в этом нет никакой проблемы >А нюкст 3 ваще дебилы раз так сделали компосиблы глобальные это очень спорное решение и у этого есть огромные недостатки, я не вижу в этом ничего хорошего, кроме “ну меньше кода писать"

на самом деле есть один плюс нет абсолютно уродских index.js которые делают только перетасовывание импортов

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

ну как сказать... с FSD эти index.js занимают 1/3 от всех файлов на старте проекта :D

Так если какой нибудь объект глобально подрубить в контекст, его так будет видно откуда и автокомлит будет в иде..

если ты пропишешь отдельно для этого типы, автокомплит не возьмется из воздуха, и тип будет по умолчанию any

Так изи же type of obj в индекс.д.тс

тебе не кажется, что проще не создавать отдельный файлик и не прописывать там типы глобальных переменных, а вместо этого воспользоваться импортом в 1 нажатие кнопки?

Ну такое

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

Нюкст 3 писали не дебилы, а для дебилов скажем так, не очень опытных разработчиков, с малым порогом входа и многими упрощениями Как бы следующий этап после Scratch