Проектирование архитектуры хранилища Vuex для больших приложений на Vue.js

[DmitryKazakov8]

Не использую VUEX в работе, так как в целом не нравится добавление дополнительного слоя в виде «мутаций». Можно вполне упростить этот код, который еще и в строках передает названия функций (facepalm)

const actions = {
  fetchVariable1({ commit }) {
    return asyncAction().then(data => commit('SET_VARIABLE_1', data))
  },
}
const mutations = {
    SET_VARIABLE_1(state, data) {
       state.variable1 = data;
    },
}

до

const actions = {
  fetchVariable1(state) {
    return asyncAction().then(data => (state.variable1 = data))
  },
}

Экшены — уже часть экосистемы стора, и если в них не проводить изменения данных, то смысла в них нет. Логично было бы оставить либо actions, либо mutations. Разработчики данной библиотеки аргументируют таким вот странным способом:

Запомните, причина, по которой мы вызываем мутацию вместо изменения store.state.count напрямую, в том, что мы хотим явным образом отслеживать её. Это простое соглашение делает наше намерение более явным, что упрощает понимание происходящих изменений состояния приложения при чтении кода. Кроме того, это позволяет использовать инструменты для отслеживания каждой мутации, создания снимков состояния или даже использования «машины времени» для отладки.

Делает явным? Ничуть, лишь удлиняет путь и размазывает логику по нескольким сущностям. Отслеживание каждой мутации, то есть вызовов мутирующих функций? В реальных приложениях это не нужно — могут быть задачи отследить, что изменился определенный параметр в сторе и предпринять соответствующие действия, а вот знать, что его изменила функция SET_VARIABLE_1 или SET_VARIABLE_ALL бывает нужно только для дебага очень запутанных приложений и можно так же быстро отловить обычным console.log. Тайм тревелинг — маркетинговая фича, добравшаяся до умов разработчиков, но реального применения у нее нет, так как если нужно сделать к примеру историю редактирования документа, то никто в здравом уме не будет полагаться на «историю действий» вместо «истории состояний». А к созданию «снимка состояний» добавление дополнительного слоя в виде mutations не имеет никакого отношения, в общем, очень слабая аргументация, берущая лишь продающим стилем изложения.

По статье — решение использовать require.context не лучшее, особенно с преобразованием имен. Таким образом ни IDE, ни человек не сможет понять, что же сейчас находится в export default modules — поможет только console.log + чтение документации к архитектуре, если она написана, а это дополнительные затраты времени. Лучше генерировать классический реэкспортный файл.

Ну и пол-статьи про то, как заменить один объект другим объектом, создав для этого функцию — как скучно, наверно, было заниматься переводом)

[become_iron]

Состояние можно сбрасывать чуть проще:

mutations: {
  resetState () {
    Object.assign(state, getState())
  }
}