При написании больших фронтенд-приложений управление состоянием может стать довольно сложной и утомительной задачей.
Для Vue.js был разработан плагин Vuex, предназначенный для управления состоянием. По умолчанию в нем выстроена следующая структура папок:
Структура папок в хранилище Vuex
Эту структуру папок можно было бы использовать в небольших приложениях, но в больших исходный код, скорее всего, будет выглядеть нечитаемо и некрасиво, а со временем с ним станет тяжело работать.
Во Vuex есть одна популярная практика — не использовать mapState и mapMutations. Вообще. Вместо это мы сразу же при создании нового значения в store делаем для него геттер, а для каждой мутации – экшен.
Что-то наподобие:
export default new Vuex.Store({
state: {
// 1
count: 0
},
getters: {
// 1
count: (state) => state.count
},
mutations: {
// 2
increment(state) {
state.count++;
}
},
actions: {
// 2
increment({ commit }) {
commit('increment');
}
}
});Холивара не избежать. Это уже доказала вот эта статья. Опять в интернете кто-то не прав, и я должен доказать почему. И я докажу.
Автор: Эван Ю (Evan You)
В течение прошлого года команда Vue работала над следующей основной (major) версией Vue.js, которую мы надеемся выпустить в первой половине 2020 года (эта работа продолжается на момент написания данной статьи). Идея новой основной версии Vue сформировалась в конце 2018 года, когда кодовой базе Vue 2 было около двух с половиной лет. Это может показаться не таким уж долгим периодом в жизни программного обеспечения, но идеи фронт-энда сильно изменились за этот период.
Пару раз понадобилось встроить в сайт справочную систему. Простенькую, с тремя колонками — общее меню, текущая статья и меню содержания статьи. Поиски готового компонента/библиотеки не привели к успеху совсем. Поэтому пришлось написать свой, который предлагается к использованию.
Когда мой проект на Vue начал разрастаться и достиг нескольких сотен компонентов, я задумался о подходе Vue и Vuex к архитектуре проекта.
