Комментарии 8
а твои способы распределять данные или выносить логику начали вызывать сложные баги, и становится все больше костылей.
Я ещё в первой части просил вас дать реальный пример, в котором можно увидеть, почему описанная вами проблема происходит, и на 90% это будет скорее всего из-за неправильной архитектуры.
У нас огромное и сложное SPA с кучей бизнес-логики и ни разу не нужно было городить какие-то отдельные, внешние классы, да ещё и связывать их с компонентами. Если общее (данные, логика) - все лежит в сторе, если компонентное - в компоненте(ах).
Все ещё не понятно, почему вы класс с данными и какой-то логикой называете сервисом. Сервисом чего он является?
Если вам действительно необходим некий общий сервис с реактивностью, почему просто не импортировать его и вызывать его фии для получения или установки каких-то его состояний? Реактивность можно добавить, через computed/watch в самом компоненте, где это необходимо, причём будет чётко видно что за сервис и как вы его используете, без какой либо внутренней магии.
Вобщем, без реального примера понять зачем это все понадобилось конкретно вам - невозможно. Как и понять верность выбора и плюсы вашего решения.
P. S. Зачем используете proxy для readonly? Почему не обычный сеттер?
Так а почему не перейти просто на vue 2.7 и пользоваться системой реактивности из vue3? Изобретать велосипеды и шокировать психику разработчиков этими велосипедами как смысл жизни?
Подскажите пожалуйста, каким образом система реактивности Vue 3 решит такие проблемы, как сохранение реактивности, валидация, защита данных (т.е. запрет на изменения)?
Несмотря на то, что я показываю решение на Vue 2, но суть этой конкретной части сводится к тому, как спроектировать класс так, чтобы с ним было удобно и безопасно работать. И те примеры организации работы с данными подходят на самом деле для любой версии Vue.
Конкретно то, как класс встраивается - про это я писала в UPD, что так он был встроен для показа примеров, это не лучшее решение. Но это база, на чем строится уже моё решение.
Ваша задача решается проще через vue2.7+. Вы можете использовать reactive вне vue-класса. И объявлять реактивное свойство где угодно. Но это чаще костыль.
И я не понимаю, почему не взять pinia, которая больше подходит куда лучше и реализует функционал, который полностью закрывает ваши потребности.
Да, можно использовать
reactiveдля версии vue 2.7+, я показала решение для проектов, где нетreactiveили где весь проект написан на Options Api и разработчики не хотят смешивать стили.
Для Vue 3 я вижу решение по-другому, так что когда я до неё дойду, я сделаю апдейт своего решения.
Я не работала плотно с Pinia, но своей сути это не меняет. Это стейт-менеджер, его цель иная - глобально распространять данные. Моя цель состоит не в этом, а в сервисах, у которых больше требований к реализации и они по определению не могут быть глобальными.
Есть очень трудозатратные сервисы, поэтому важно, чтобы они создавались только в момент когда нужны, и удалялись из памяти когда не нужны.
Есть сервисы, которые должны откатываться к изначальному состоянию, и класс ты можешь просто пересоздать и привязаться к новому экземпляру, а стейт нет.
Есть сервисы, которые должны существовать в нескольких экземплярах одновременно, что также не способствует основной цели стора.
Просто в данной части статьи я сосредоточилась на том, как спроектировать класс, чтобы ничего не поломалось, потому что нет смысла во всех этих дополнительных экземплярах, если это просто будет невозможно нормально встроить.
Пока я исследовала возможности классов в компонентах, я обнаружила, что есть чёткие требования, как должна быть организована та или иная функциональность, чтобы данные не терялись - так что в этой части я сосредоточилась на этих требованиях.
Ничего не мешает юзать pinia в options api.
«pinia - стейт менеджер» и «глобально распространять» - это странная аргументация.
В посте у Вас сервис запрашивает товары (хотя это связка стейтменеджера и слоя api). А сейчас Вы приводите в пример совершенно другие вещи. Стор можно откатывать. Можно сделать фабрику сторов. Можно вкладывать сторы. «Трудозатратные» - нужна конкретика.
Почему бы не юзать «сервисы» через слой стора?
Вы предлагаете решение для небольшого класса узкоспециализированных задач, но представляете его как универсальное.
И я знаю о чем говорю: у меня есть такие «сервисы»: работа с webworker, работа с камерами и т.д., только для их использования не нужно писать статьи. Vue2 и так умеет привязывать поле инстанса нативного класса к computed-свойству. А для 2.7+ достаточно юзать reactive (пришлось внедрить при переезде, из коробки не подхватилось).
И я вот не уверен, что сервисы - это хорошее решение.
Я был бы рад почитать статью, которая ответит на вопрос «зачем».
Вот вам уже второй человек говорит что стоит использовать реактивность Vue 3, присмотритесь к ней.
Сервисная архитектура во Vue 2 | Проектирование класса (примитивы и объекты)