СР
Смысл от еще одного слоя под сервисы? Экшены с этим отлично справляются, ну и слоя апи достаточно имхо
Долго рассуждать,... Не сейчас
Size: a a a
2020 December 24
СР
ну мне лично vuex видится больше как репозиторий (как паттерн) с плюшками реактивности. на этом его зона ответственности заканчивается. сущности все живут в классах отдельных и генерятся по факту необходимости, из стора лишь данные получая.
Можно и так, главное чтоб команда понимала, и те кто придёт позже эту кашу саппортить 😂
K
Смысл от еще одного слоя под сервисы? Экшены с этим отлично справляются, ну и слоя апи достаточно имхо
простой кейс. у тебя несколько однотипных счетчиков, обновляющих некоторые данные с бэка. на одной вьюхе тебе надо один счетчик запустить, на другой пяток одинаковых ходящих по разным урлам. как будешь их идентифицировать? айдишники каждому придумывать?
K
Можно и так, главное чтоб команда понимала, и те кто придёт позже эту кашу саппортить 😂
каша получается во вьюиксе )) а так все по полочкам, слоями )
V
простой кейс. у тебя несколько однотипных счетчиков, обновляющих некоторые данные с бэка. на одной вьюхе тебе надо один счетчик запустить, на другой пяток одинаковых ходящих по разным урлам. как будешь их идентифицировать? айдишники каждому придумывать?
ничего не понял
СР
простой кейс. у тебя несколько однотипных счетчиков, обновляющих некоторые данные с бэка. на одной вьюхе тебе надо один счетчик запустить, на другой пяток одинаковых ходящих по разным урлам. как будешь их идентифицировать? айдишники каждому придумывать?
Да. Я бы сделал в сервисе типищированный метод, получающих данные по ид счётчика, и компонент дёргает то что нужно, не засоряя общий стейт
K
ничего не понял
проблема в инкапсуляции. я, пардон, хочу, чтобы методы обработки данных жили в том же объекте, что и данные ) если есть корзина и есть товар, товар должен сам уметь положить себя в корзину (корзина добавить в себя товар) не дергая внешние методы. это та бизнес-логика, которая не должна жить за пределами своего домена
K
а корзина суметь посчитать свою сумму и выдать ее своим геттером, самостоятельно ))
V
проблема в инкапсуляции. я, пардон, хочу, чтобы методы обработки данных жили в том же объекте, что и данные ) если есть корзина и есть товар, товар должен сам уметь положить себя в корзину (корзина добавить в себя товар) не дергая внешние методы. это та бизнес-логика, которая не должна жить за пределами своего домена
не вижу никаких проблем с отдельным методом/экшеном в сторе, который принимает товар. Если они повторяются - модули в помощь
K
есть разница между
basket.total()и
total(basket)
СР
проблема в инкапсуляции. я, пардон, хочу, чтобы методы обработки данных жили в том же объекте, что и данные ) если есть корзина и есть товар, товар должен сам уметь положить себя в корзину (корзина добавить в себя товар) не дергая внешние методы. это та бизнес-логика, которая не должна жить за пределами своего домена
Да, верная мысль. Но только не всегда прям нужно все в вуекс пихать. Имно, только расшаренные данные, и каплинг (связь) =>событие где-то меняет стейт, а не стейт сам себя
K
Да, верная мысль. Но только не всегда прям нужно все в вуекс пихать. Имно, только расшаренные данные, и каплинг (связь) =>событие где-то меняет стейт, а не стейт сам себя
ну мне лично ближе предметное проектирование, да и проект такой. там под сотню разных сущностей с кучей фронтовой логики. с голым vuex сдохли бы все
V
ну мне лично ближе предметное проектирование, да и проект такой. там под сотню разных сущностей с кучей фронтовой логики. с голым vuex сдохли бы все
а как вы реализовали? Диспатчить то за пределами вуекса нельзя
СР
ну мне лично ближе предметное проектирование, да и проект такой. там под сотню разных сущностей с кучей фронтовой логики. с голым vuex сдохли бы все
Я не спорю!!
Каждый проект-своя пуля!
Каждый проект-своя пуля!
K
а как вы реализовали? Диспатчить то за пределами вуекса нельзя
класс модели в конструкторе принимает вуекс данные, все апдейты через универсальные мутации, которые в глубине системы единожды реализованы. на выходе во вьюхах есть класс модели с данными и методами и есть сервисы дополнительные, реализующие логику приложения
СР
класс модели в конструкторе принимает вуекс данные, все апдейты через универсальные мутации, которые в глубине системы единожды реализованы. на выходе во вьюхах есть класс модели с данными и методами и есть сервисы дополнительные, реализующие логику приложения
Кстати, как боролся с тем что накст то весь стейт сериалищует в джейсон, и при спа, ты получишь pojo
K
В накст только залез, да и то он интересен как статика только. Но по сути с pojo только работа и идет
K
Мы не можем хранить готовые экземпляры в стейте. И ругаться будет и вообще антипаттерн
СР
Мы не можем хранить готовые экземпляры в стейте. И ругаться будет и вообще антипаттерн
Ну не сказал бы, решаемо, toJson переопределяешь у модельки, а если нужны и методы то в маунтед воссозлаешь объект (я class-transformer пользую), через #опу, конечно, но пока так
K
у модельки есть некие служебные данные, типа $pending, пока аксиос на сервер бегает, и вести его мимо стора чревато его же руганью на мутации левые