🥲 спасибо большое

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

отдельно пагинация, форма поиска, и к примеру на списке продуктов есть кнопка "обновить"

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

мне вот понравилось как сдесь сделали https://nuxtjs.org/docs/2.x/directory-structure/plugins/#inject-in-root--context

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

Тем что явное лучше неявного

Мне не нравится внедрение в чужие контексты - это по сути тот же prototype pollution только под другим соусом

про pollution понял, но так ж делают, тот же vuex, vue-router...
вашу сторону понимаю, но мне удобно так)

по факту у меня получаеться this.$api в компоненте и мне так удобно...

спс за объяснение)

Я понимаю про удобно, но это кому-то потом поддерживать

Разница - в одной строчке импорта, и ради этого городить проектно-специфичный подход явно не стоит

И более того, вот с точки зрения здравого смысла

Что у меня в this - компонент

Код this.$api для меня читается как "апи компонента" или "апи для компонента"

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

Работа через this заставит просмотреть весь код компонента чтобы понять "а что ему надо"

Зачем это понимать? Тысячи причин, от переноса компонента в другой проект до написания тестов

"Код this.$api для меня читается как "апи компонента" или "апи для компонента""

тут да... интересно вобщем... правда переносить компоненти между проеками не приходилось...

спс, за дискусию, подумаю на досуге)

Ребят, всем привет - вопрос дня)
Как вы называете у себя в проекте модуль, реализующий слой с БЛ?
(где обычно у вас лежит store, actions/effects, reducer и т.д.)

Холиварчик тут среди коллег по цеху, надо понять какое понятие сейчас больше юзается)

Стейт-менеджмент больше подходит на infrastructure layer и не должен реализовывать бизнес-логику

Ну я условно про такой случай:
feature/some-feat/
   - ui # Визуальная логика
   - store / state / model # Бизнес-логика

В вопросе ответ, "сейчас больше юзается" )

а где ее ещё писать 😳

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

Например в классах моделей или сервисах. Стейт-менеджер не лучшее место

Ну да, я скорее вот про такую вещь)

а сервисы в таком случае это уже не стейт что ли

Тип что можно все эти actions/reducers/thunks/sagas/epics и т.д. назвать каким-нибудь одним словом

А при чем тут сервис к стейту?

ну сервис же так или иначе будет хранить состояние

Вообще не обязательно