Pull to refresh

Comments 16

знакомые ощущения =). Пробовал те же инструменты.
Посмотрите это github.com/sascha245/vuex-simple, работает даже с SSR без всяких «танцев с бубном».

Интересно, а работоспособно ли решение в контексте SSR?


import { counterModule } from '@/store/modules/counterModule'

Этот код выглядит как глобальный статичный стейт на всё приложение. Очень хотелось бы, чтобы это было не так. Иначе SSR не полетит.

Ох и натанцевались мы на работе в своё время. Полезли кривыми руками SSR прикручивать и в итоге у нас получилось, что один авторизовался и его сессия на всех посетителей шарится ))
Для избежания таких проблем достаточно придерживаться рекомендаций с ssr.vuejs.org.
vuexok не призван заменить api vuex, он добавляет немного магии для поддержки typescript, а так это тот же vuex, тем же api и с теми же возможностями. Фактически createModule просто вызывает store.registerModule. Сейчас не было цели сделать удобную поддержку ssr, но почему бы не сделать ее явной из коробки) Думаю в ближайшее время появится в документации инструкция для ssr
А без наследования будет очень много дублирования кода.
А что вы там наследуете???

Вообще, типичная ситуация, когда что-то отдано на откуп сообществу — куча велосипедов с «фатальным недостатком» разной степени костыльности, каждый из которых написан и поддерживается (или уже не поддерживается) одним-единственным человеком.
Многие модули совершают похожие операции (например CRUD)
Очень бы не хотелось для таких вещей заниматься «копипастом». В ближайшее время будет статья о этой проблеме в контексте чистого vuex, а т.к. vuexok не заменяет api vuex, то решение которое будет представлено в этой статье (впрочем как и все другие решения) будут работать и для vuexok.
Я пришлю ссылку когда статья будет готова.
Не понимаю, причём здесь CRUD, если модуль хранилища — это просто набор глобальных переменных с областью видимости, реактивностью и отслеживанием изменений.
Совершенно не только. Да, vuex в первую очередь используется для хранения состояния приложения и реализует концепции «однонаправленного потока данных»
image
Vuex так же берет на себя «действия». Подробнее тут vuex.vuejs.org/guide/actions.html
И всё-таки, причём здесь CRUD? Или вы в хранилище всю вашу логику пихаете вместо сервисов?
Маленький пример, допустим у нас новостной сайт.
У нас есть статьи. Мы можем их удалять/редактировать/получать

Пусть vue занимается тем чем должен заниматься — отрисовывает страницы/компоненты, реализует какую-то логику работы с ui, т.к. vue в первую очередь решает задачи уровня представления (Vue Introduction).
А всю работу с состоянием (хранение, доставка состояния до компонентов, получение состояния, изменение) возьмет на себя vuex.

Тогда накидаем сразу стор:
{
  state: {
    text: ''
  },
  mutations: {
    setText(state, text) {
      state.text = text
    },
    setId(state, id) {
      state.id = id
    }
  },
  actions: {
    async loadArticle(injectee) {
      const text = await loadArticle(injectee.state.id)
      injectee.commit('setText', text)
    },
    async edit(injectee, text) {
      await updateArticle(injectee.state.id, text)
      injectee.commit('setText', text)
    },
    await remove(injectee) {
      await removeArticle(injectee.state.id)
      injectee.commit('setText', '')
    }
  }
}

Пока все хорошо, отмечу что это очень синтетический пример. В реальном приложение будет еще какой-нибудь throttle, обработка ошибок, статус загрузки статьи (загружаем/загружено) и что-нибудь еще

Далее допустим у нас появляются еще комментарии, которые должны уметь всё то же самое. Первое что приходит в голову — копипаст. Но это утопия если подобных сущностей как статьи и комментарии у вас в проекте не 2-3, а 10-15. Вот тут было бы здорово иметь возможность «наследовать» модули, что бы не дублировать одну и туже логику. Сразу поясню, что я тут имею ввиду наследование не в классическом ООП понимание. Тут скорее наследование в значение — делает то же самое, но чуть-чуть иначе (например отсылать запросы на другой эндпоинт).

Использовать vuex только для хранения данных, а отправлять запросы о обрабатывать результат их работы в компонентах тоже плохой вариант, т.к. повторяющаяся логика работы с состоянием останется, просто она будет размазана по всему приложению.
Что касается сервисов — на мой взгляд это правильный подход, но бывают частные случаи когда лучше без них. И если вы не решаете специфичные задачи, c vuex чаще всего сервисы не нужны.

Как я говорил ранее скоро будет статья посвещенная этой теме. Там будет openapi-generator + vuex
Художники так видят. Наследуют круды в сторах
Во всех подобных случаях кажется что люди с переменным успехом пытаются переизобрести Angular и rx
Совсем нет) Даже не близко
Будет близко еще через несколько итераций. Для начало бы неплохо закон Деметры соблюсти.
Мне как фронтендеру, который 100% времени пишет на vue, редко приходится о нем вспоминать. Так что, возможно я что-то упустил. Подскажите в чем конкретно проблема?
Не думаю что последующие итерации внесут хоть какие-нибудь значительные изменения. Более краткого и лаконичного использования модулей vuex сложно представить даже в идеальном мире.
Важный момент что речь идет именно про модули и задача ставится не сделать замену vuex, а просто прикрутить к нему typescript без серьёзных изменений в использование vuex (api)
Sign up to leave a comment.

Articles