Comments 16
знакомые ощущения =). Пробовал те же инструменты.
Посмотрите это github.com/sascha245/vuex-simple, работает даже с SSR без всяких «танцев с бубном».
Посмотрите это github.com/sascha245/vuex-simple, работает даже с SSR без всяких «танцев с бубном».
+1
Интересно, а работоспособно ли решение в контексте SSR?
import { counterModule } from '@/store/modules/counterModule'
Этот код выглядит как глобальный статичный стейт на всё приложение. Очень хотелось бы, чтобы это было не так. Иначе SSR не полетит.
+1
Ох и натанцевались мы на работе в своё время. Полезли кривыми руками SSR прикручивать и в итоге у нас получилось, что один авторизовался и его сессия на всех посетителей шарится ))
+3
Для избежания таких проблем достаточно придерживаться рекомендаций с ssr.vuejs.org.
vuexok не призван заменить api vuex, он добавляет немного магии для поддержки typescript, а так это тот же vuex, тем же api и с теми же возможностями. Фактически createModule просто вызывает store.registerModule. Сейчас не было цели сделать удобную поддержку ssr, но почему бы не сделать ее явной из коробки) Думаю в ближайшее время появится в документации инструкция для ssr
vuexok не призван заменить api vuex, он добавляет немного магии для поддержки typescript, а так это тот же vuex, тем же api и с теми же возможностями. Фактически createModule просто вызывает store.registerModule. Сейчас не было цели сделать удобную поддержку ssr, но почему бы не сделать ее явной из коробки) Думаю в ближайшее время появится в документации инструкция для ssr
0
А без наследования будет очень много дублирования кода.А что вы там наследуете???
Вообще, типичная ситуация, когда что-то отдано на откуп сообществу — куча велосипедов с «фатальным недостатком» разной степени костыльности, каждый из которых написан и поддерживается (или уже не поддерживается) одним-единственным человеком.
+1
Многие модули совершают похожие операции (например CRUD)
Очень бы не хотелось для таких вещей заниматься «копипастом». В ближайшее время будет статья о этой проблеме в контексте чистого vuex, а т.к. vuexok не заменяет api vuex, то решение которое будет представлено в этой статье (впрочем как и все другие решения) будут работать и для vuexok.
Я пришлю ссылку когда статья будет готова.
Очень бы не хотелось для таких вещей заниматься «копипастом». В ближайшее время будет статья о этой проблеме в контексте чистого vuex, а т.к. vuexok не заменяет api vuex, то решение которое будет представлено в этой статье (впрочем как и все другие решения) будут работать и для vuexok.
Я пришлю ссылку когда статья будет готова.
0
Не понимаю, причём здесь CRUD, если модуль хранилища — это просто набор глобальных переменных с областью видимости, реактивностью и отслеживанием изменений.
0
Совершенно не только. Да, vuex в первую очередь используется для хранения состояния приложения и реализует концепции «однонаправленного потока данных»
Vuex так же берет на себя «действия». Подробнее тут vuex.vuejs.org/guide/actions.html
Vuex так же берет на себя «действия». Подробнее тут vuex.vuejs.org/guide/actions.html
0
И всё-таки, причём здесь CRUD? Или вы в хранилище всю вашу логику пихаете вместо сервисов?
+1
Маленький пример, допустим у нас новостной сайт.
У нас есть статьи. Мы можем их удалять/редактировать/получать
Пусть vue занимается тем чем должен заниматься — отрисовывает страницы/компоненты, реализует какую-то логику работы с ui, т.к. vue в первую очередь решает задачи уровня представления (Vue Introduction).
А всю работу с состоянием (хранение, доставка состояния до компонентов, получение состояния, изменение) возьмет на себя vuex.
Тогда накидаем сразу стор:
Пока все хорошо, отмечу что это очень синтетический пример. В реальном приложение будет еще какой-нибудь throttle, обработка ошибок, статус загрузки статьи (загружаем/загружено) и что-нибудь еще
Далее допустим у нас появляются еще комментарии, которые должны уметь всё то же самое. Первое что приходит в голову — копипаст. Но это утопия если подобных сущностей как статьи и комментарии у вас в проекте не 2-3, а 10-15. Вот тут было бы здорово иметь возможность «наследовать» модули, что бы не дублировать одну и туже логику. Сразу поясню, что я тут имею ввиду наследование не в классическом ООП понимание. Тут скорее наследование в значение — делает то же самое, но чуть-чуть иначе (например отсылать запросы на другой эндпоинт).
Использовать vuex только для хранения данных, а отправлять запросы о обрабатывать результат их работы в компонентах тоже плохой вариант, т.к. повторяющаяся логика работы с состоянием останется, просто она будет размазана по всему приложению.
Что касается сервисов — на мой взгляд это правильный подход, но бывают частные случаи когда лучше без них. И если вы не решаете специфичные задачи, c vuex чаще всего сервисы не нужны.
Как я говорил ранее скоро будет статья посвещенная этой теме. Там будет openapi-generator + vuex
У нас есть статьи. Мы можем их удалять/редактировать/получать
Пусть 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
0
Художники так видят. Наследуют круды в сторах
0
Во всех подобных случаях кажется что люди с переменным успехом пытаются переизобрести Angular и rx
-1
Совсем нет) Даже не близко
0
Будет близко еще через несколько итераций. Для начало бы неплохо закон Деметры соблюсти.
0
Мне как фронтендеру, который 100% времени пишет на vue, редко приходится о нем вспоминать. Так что, возможно я что-то упустил. Подскажите в чем конкретно проблема?
0
Не думаю что последующие итерации внесут хоть какие-нибудь значительные изменения. Более краткого и лаконичного использования модулей vuex сложно представить даже в идеальном мире.
Важный момент что речь идет именно про модули и задача ставится не сделать замену vuex, а просто прикрутить к нему typescript без серьёзных изменений в использование vuex (api)
Важный момент что речь идет именно про модули и задача ставится не сделать замену vuex, а просто прикрутить к нему typescript без серьёзных изменений в использование vuex (api)
0
Sign up to leave a comment.
vuex + typescript = vuexok. Велосипед, который поехал и обогнал всех