Pull to refresh

Comments 8

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

Я ещё в первой части просил вас дать реальный пример, в котором можно увидеть, почему описанная вами проблема происходит, и на 90% это будет скорее всего из-за неправильной архитектуры.

У нас огромное и сложное SPA с кучей бизнес-логики и ни разу не нужно было городить какие-то отдельные, внешние классы, да ещё и связывать их с компонентами. Если общее (данные, логика) - все лежит в сторе, если компонентное - в компоненте(ах).

Все ещё не понятно, почему вы класс с данными и какой-то логикой называете сервисом. Сервисом чего он является?

Если вам действительно необходим некий общий сервис с реактивностью, почему просто не импортировать его и вызывать его фии для получения или установки каких-то его состояний? Реактивность можно добавить, через computed/watch в самом компоненте, где это необходимо, причём будет чётко видно что за сервис и как вы его используете, без какой либо внутренней магии.

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

P. S. Зачем используете proxy для readonly? Почему не обычный сеттер?

Так а почему не перейти просто на vue 2.7 и пользоваться системой реактивности из vue3? Изобретать велосипеды и шокировать психику разработчиков этими велосипедами как смысл жизни?

Подскажите пожалуйста, каким образом система реактивности Vue 3 решит такие проблемы, как сохранение реактивности, валидация, защита данных (т.е. запрет на изменения)?

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

Конкретно то, как класс встраивается - про это я писала в UPD, что так он был встроен для показа примеров, это не лучшее решение. Но это база, на чем строится уже моё решение.

Все ответы на эти вопросы на самом деле есть в документации Vue 3, не вижу смысла тут её переписывать, просто ознакомьтесь с ней поглубже.

Ваша задача решается проще через vue2.7+. Вы можете использовать reactive вне vue-класса. И объявлять реактивное свойство где угодно. Но это чаще костыль.

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

  1. Да, можно использовать reactive для версии vue 2.7+, я показала решение для проектов, где нет reactive или где весь проект написан на Options Api и разработчики не хотят смешивать стили.

Для Vue 3 я вижу решение по-другому, так что когда я до неё дойду, я сделаю апдейт своего решения.

  1. Я не работала плотно с Pinia, но своей сути это не меняет. Это стейт-менеджер, его цель иная - глобально распространять данные. Моя цель состоит не в этом, а в сервисах, у которых больше требований к реализации и они по определению не могут быть глобальными.

Есть очень трудозатратные сервисы, поэтому важно, чтобы они создавались только в момент когда нужны, и удалялись из памяти когда не нужны.

Есть сервисы, которые должны откатываться к изначальному состоянию, и класс ты можешь просто пересоздать и привязаться к новому экземпляру, а стейт нет.

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

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

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

Ничего не мешает юзать pinia в options api.

«pinia - стейт менеджер» и «глобально распространять» - это странная аргументация.

В посте у Вас сервис запрашивает товары (хотя это связка стейтменеджера и слоя api). А сейчас Вы приводите в пример совершенно другие вещи. Стор можно откатывать. Можно сделать фабрику сторов. Можно вкладывать сторы. «Трудозатратные» - нужна конкретика.

Почему бы не юзать «сервисы» через слой стора?

Вы предлагаете решение для небольшого класса узкоспециализированных задач, но представляете его как универсальное.

И я знаю о чем говорю: у меня есть такие «сервисы»: работа с webworker, работа с камерами и т.д., только для их использования не нужно писать статьи. Vue2 и так умеет привязывать поле инстанса нативного класса к computed-свойству. А для 2.7+ достаточно юзать reactive (пришлось внедрить при переезде, из коробки не подхватилось).

И я вот не уверен, что сервисы - это хорошее решение.

Я был бы рад почитать статью, которая ответит на вопрос «зачем».

Вот вам уже второй человек говорит что стоит использовать реактивность Vue 3, присмотритесь к ней.

Sign up to leave a comment.

Articles