есть такое, но это плохая практика https://v3.vuejs.org/guide/migration/global-api.html#vue-prototype-replaced-by-config-globalproperties
Provide / Inject - получилось через них сделать)) спасибо!
а зачем тебе "глобальный метод"?
чтобы в компонентах использовать firebase без импорта
Если ты пишешь не наколеночный пет-проект, то лучше так не делать
а посоветуй)) вообще наколеночный проект, но хотелось бы использовать бест практик
А как же axios, vuex и прочие?
Всё +- то же самое, только немного по-другому
Зависит от того, что ты хочешь сделать, как правило, у тебя есть 1 умный компонент, который взаимодействует с http клиентом, стором, заключает в себе бизнес-логику и передает данные дочерним презентационным компонентам (компонентам UI) и в реальности тебе не нужно чтобы каждый компонент в твоем проекте был тесно связан с той или иной API реализацией
вот, в сообщении выше простейшая реализация
В чём экономия, если эти "глобальные" объекты у каждого компонента суть есть ссылка на один и тот же объект?
Это не экономия, это компонентный подход, чем меньше компонент знает о том, в каком контексте он сущетсвует, тем более он переиспольуземый, это не говоря про DI и тестирование
В целом согласен, просто не могу понять, почему глобальные функции это плохо, ибо если компонент их внутри себя не использует, то и есть они не просят. Никто же не заставляет реализовать компоненты таким образом, чтобы они самостоятельно стучались к стору или api, вместо прокидывания пропсов, если такая возможность имеется в рамках проекта
потому что используя в компоненте условный $axios, ты смешиваешь слои данных и отображения
Никто не заставляет тебя в условном itempicker'e дёргать axios
не важно где ты его дергаешь, важно, что сама логика запроса протекает в компонент
Целая пачка против: 1. Ты ломаешь архитектуру 2. Мы на работе работаем не по 1 челоеку на проект, и как ты будешь обрабатывать кейс, когда тебе коллега скажет - "вот тут, ты вместо того чтобы подумать закастылял глобальный доступ, почему я не могу?" и будет прав 3. Это антипаттерн 4. Это костыль. указывающий на то, что ты не знаешь как решить задачу корректным путем 5. Ты разрываешь прозрачное представление разделения логики / сервисов / вьюшки 6. etc...
Со вторым очень согласен, остальное работает только в том случае, если ты используешь логику, заложенную в эти объекты
Обсуждают сегодня