В Vuex, какова логика наличия как "действий", так и "мутаций?"
Я понимаю логику компонентов, которые не могут изменять состояние (что кажется умным), но наличие как действий, так и мутаций кажется, что вы пишете одну функцию для запуска другой функции, чтобы затем изменить состояние.
В чем разница между "действиями" и "мутациями", как они работают вместе, и более того, мне любопытно, почему разработчики Vuex решили сделать это таким образом?
Вопрос 1: Почему разработчики Vuejs решили сделать это так?
Ответ:
Вопрос 2: Какая разница между "действием" и "мутацией"?
Давайте сначала посмотрим на официальное объяснение:
Мутации:
Мутации Vuex - это по существу события: каждая мутация имеет имя и обработчик.
import Vuex from 'vuex' const store = new Vuex.Store({ state: { count: 1 }, mutations: { INCREMENT (state) { // mutate state state.count++ } } })Действия: Действия - это просто функции, которые отправляют мутации.
// the simplest action function increment (store) { store.dispatch('INCREMENT') } // a action with additional arguments // with ES2015 argument destructuring function incrementBy ({ dispatch }, amount) { dispatch('INCREMENT', amount) }
Вот мое объяснение выше:
Мутации являются синхронными, тогда как действия могут быть асинхронными.
Иными словами: вам не нужны действия, если ваши операции синхронны, иначе реализуйте их.
Я считаю, что понимание мотиваций, стоящих за мутациями и действиями, позволяет лучше судить о том, когда использовать, что и как. Это также освобождает программиста от бремени неопределенности в ситуациях, когда "правила" становятся нечеткими. Немного рассуждая об их соответствующих целях, я пришел к выводу, что, хотя могут быть неправильные способы использования действий и мутаций, я не думаю, что существует канонический подход.
Давайте сначала попытаемся понять, почему мы даже совершаем мутации или действия.
Зачем идти по шаблону в первую очередь? Почему бы не изменить состояние непосредственно в компонентах?
Строго говоря, вы можете изменить state непосредственно из ваших компонентов. state - это просто объект JavaScript, и в нем нет ничего волшебного, что могло бы отменить изменения, которые вы внесли в него.
// Yes, you can!
this.$store.state['products'].push(product)
Однако, делая это, вы разбрасываете мутации своего состояния повсюду. Вы теряете возможность просто открыть один модуль, в котором находится состояние, и сразу увидеть, какие операции могут быть применены к нему. Централизованные мутации решают эту проблему, хотя и за счет некоторого шаблона.
// so we go from this
this.$store.state['products'].push(product)
// to this
this.$store.commit('addProduct', {product})
...
// and in store
addProduct(state, {product}){
state.products.push(product)
}
...
Я думаю, что если вы замените что-то короткое на шаблон, вы захотите, чтобы шаблон также был маленьким. Поэтому я предполагаю, что мутации должны быть очень тонкими обертками вокруг нативных операций над состоянием, почти без бизнес-логики. Другими словами, мутации предназначены для использования в основном как сеттеры.
Теперь, когда вы централизовали свои мутации, у вас есть лучший обзор изменений вашего состояния, и поскольку ваш инструментарий (vue-devtools) также знает об этом месте, это облегчает отладку. Стоит также иметь в виду, что многие плагины Vuex не отслеживают состояние напрямую, чтобы отслеживать изменения, а скорее полагаются на мутации. Таким образом, изменения состояния невидимы для них.
Так
mutations,actionsкакая разница?
Действия, такие как мутации, также находятся в модуле хранилища и могут получать объект state. Что подразумевает, что они также могут мутировать его напрямую. Так какой смысл иметь оба? Если мы рассуждаем о том, что мутации должны быть небольшими и простыми, это означает, что нам нужны альтернативные средства для размещения более сложной бизнес-логики. Действия являются средством сделать это. И поскольку, как мы установили ранее, vue-devtools и плагины знают об изменениях посредством мутаций, чтобы оставаться последовательными, мы должны продолжать использовать мутации из наших действий. Кроме того, поскольку все действия должны охватывать все объекты, а логика, которую они инкапсулируют, может быть асинхронной, то имеет смысл, что действия с самого начала просто делались бы асинхронными.
Часто подчеркивалось, что действия могут быть асинхронными, а мутации - нет. Вы можете решить рассматривать различие как указание на то, что мутации должны использоваться для чего-то синхронного (и действия для чего-либо асинхронного); тем не менее, вы столкнетесь с некоторыми трудностями, если, например, вам нужно будет зафиксировать более одной мутации (синхронно), или если вам нужно работать с геттером из ваших мутаций, поскольку функции мутации не получают ни геттеры, ни мутации в качестве аргументов...
... что приводит к интересному вопросу.
Почему мутации не получают геттеры?
Я еще не нашел удовлетворительного ответа на этот вопрос. Я видел некоторые объяснения со стороны основной команды, что я нашел спор в лучшем случае. Если я резюмирую их использование, то предполагается, что геттеры являются вычисляемыми (и часто кэшируемыми) расширениями состояния. Другими словами, они в основном все еще находятся в состоянии, хотя требуют предварительных вычислений и обычно доступны только для чтения. По крайней мере, так их рекомендуют использовать.
Таким образом, предотвращение прямого доступа мутаций к геттерам означает, что теперь необходима одна из трех вещей, если нам необходимо получить доступ от первого к некоторым функциональным возможностям, предлагаемым последним: (1) либо вычисления состояний, предоставляемые геттером, дублируются где-то, что доступно в Мутацию (неприятный запах), или (2) вычисленное значение (или соответствующий сам Геттер) передается в качестве явного аргумента Мутации (фанки), или (3) сама логика Геттера дублируется непосредственно в Мутации без дополнительного преимущества кэширования, предоставляемого Getter (stench).
Ниже приведен пример (2), который в большинстве сценариев, с которыми я сталкивался, кажется "наименее плохим" вариантом.
state:{
shoppingCart: {
products: []
}
},
getters:{
hasProduct(state){
return function(product) { ... }
}
}
actions: {
addProduct({state, getters, commit, dispatch}, {product}){
// all kinds of business logic goes here
// then pull out some computed state
const hasProduct = getters.hasProduct(product)
// and pass it to the mutation
commit('addProduct', {product, hasProduct})
}
}
mutations: {
addProduct(state, {product, hasProduct}){
if (hasProduct){
// mutate the state one way
} else {
// mutate the state another way
}
}
}
Мне кажется, что вышесказанное выглядит не только немного запутанным, но и несколько "дырявым", поскольку часть кода, присутствующего в Action, явно вытекает из внутренней логики Mutation.
На мой взгляд, это показатель компромисса. Я считаю, что разрешение мутациям автоматически получать геттеров сопряжено с некоторыми трудностями. Это может быть либо дизайн самого Vuex, либо инструментария (vue-devtools et al), либо сохранение некоторой обратной совместимости, либо некоторая комбинация всех заявленных возможностей.
Я не верю в то, что передача Геттеров своим Мутациям сама по себе является признаком того, что вы делаете что-то не так. Я считаю это просто "исправлением" одного из недостатков фреймворка.
Я думаю, что ответ TL;DR заключается в том, что мутации должны быть синхронными/транзакционными. Поэтому, если вам нужно запустить вызов Ajax или сделать любой другой асинхронный код, вам нужно сделать это в Action, а затем зафиксировать мутацию после, чтобы установить новое состояние.
Отказ от ответственности - я только начал использовать vuejs, так что это только я, экстраполирующий намерение проекта.
Отладка машины времени использует моментальные снимки состояния и показывает временную шкалу действий и мутаций. Теоретически у нас могли бы быть просто actions наряду с записью штатов и геттеров для синхронного описания мутации. Но потом:
mutations но затем мы можем сказать, что транзакция должна быть улучшена, а не быть условием гонки в действиях. Анонимные мутации внутри действия могли бы легче восстановить такие ошибки, поскольку асинхронное программирование является хрупким и сложным.Сравните следующий журнал транзакций с именованными мутациями.
Action: FetchNewsStories
Mutation: SetFetchingNewsStories
Action: FetchNewsStories [continuation]
Mutation: DoneFetchingNewsStories([...])
С журналом транзакций, который не имеет названных мутаций:
Action: FetchNewsStories
Mutation: state.isFetching = true;
Action: FetchNewsStories [continuation]
Mutation: state.isFetching = false;
Mutation: state.listOfStories = [...]
Надеюсь, вы можете экстраполировать из этого примера потенциальную сложность в асинхронной и анонимной мутации внутри действий.
https://vuex.vuejs.org/en/mutations.html
Теперь представьте, что мы отлаживаем приложение и просматриваем журналы мутаций devtool. Для каждой зарегистрированной мутации devtool нужно будет захватить снимки состояния "раньше" и "после". Тем не менее, асинхронный обратный вызов внутри мутации примера выше делает невозможным: обратный вызов еще не вызывается, когда мутация совершена, и нет никакого способа, чтобы devtool знал, когда вызов будет фактически вызван - любая мутация состояния, выполняемая в обратном вызове по существу не отслеживается!
Согласно docs
Действия аналогичны мутациям, причем различия заключаются в следующем:
Рассмотрим следующий фрагмент.
const store = new Vuex.Store({
state: {
count: 0
},
mutations: {
increment (state) {
state.count++ //Mutating the state. Must be synchronous
}
},
actions: {
increment (context) {
context.commit('increment') //Committing the mutations. Can be asynchronous.
}
}
})
Обработчики действий (increment) получают объект контекста, который предоставляет тот же набор методов/свойств экземпляра хранилища, поэтому вы можете вызвать context.commit для фиксации мутации или доступа к состоянию и геттерам через context.state и context.getters
Основные различия между действиями и мутациями:
Это тоже смутило меня, поэтому я сделал простую демонстрацию.
component.vue
<template>
<div id="app">
<h6>Logging with Action vs Mutation</h6>
<p>{{count}}</p>
<p>
<button @click="mutateCountWithAsyncDelay()">Mutate Count directly with delay</button>
</p>
<p>
<button @click="updateCountViaAsyncAction()">Update Count via action, but with delay</button>
</p>
<p>Note that when the mutation handles the asynchronous action, the "log" in console is broken.</p>
<p>When mutations are separated to only update data while the action handles the asynchronous business
logic, the log works the log works</p>
</div>
</template>
<script>
export default {
name: 'app',
methods: {
//WRONG
mutateCountWithAsyncDelay(){
this.$store.commit('mutateCountWithAsyncDelay');
},
//RIGHT
updateCountViaAsyncAction(){
this.$store.dispatch('updateCountAsync')
}
},
computed: {
count: function(){
return this.$store.state.count;
},
}
}
</script>
store.js
import 'es6-promise/auto'
import Vuex from 'vuex'
import Vue from 'vue';
Vue.use(Vuex);
const myStore = new Vuex.Store({
state: {
count: 0,
},
mutations: {
//The WRONG way
mutateCountWithAsyncDelay (state) {
var log1;
var log2;
//Capture Before Value
log1 = state.count;
//Simulate delay from a fetch or something
setTimeout(() => {
state.count++
}, 1000);
//Capture After Value
log2 = state.count;
//Async in mutation screws up the log
console.log('Starting Count: ${log1}'); //NRHG
console.log('Ending Count: ${log2}'); //NRHG
},
//The RIGHT way
mutateCount (state) {
var log1;
var log2;
//Capture Before Value
log1 = state.count;
//Mutation does nothing but update data
state.count++;
//Capture After Value
log2 = state.count;
//Changes logged correctly
console.log('Starting Count: ${log1}'); //NRHG
console.log('Ending Count: ${log2}'); //NRHG
}
},
actions: {
//This action performs its async work then commits the RIGHT mutation
updateCountAsync(context){
setTimeout(() => {
context.commit('mutateCount');
}, 1000);
}
},
});
export default myStore;
Изучив это, я пришел к выводу, что мутации - это конвенция, ориентированная только на изменение данных, чтобы улучшить отдельные проблемы и улучшить регистрацию до и после обновленных данных. В то время как действия представляют собой уровень абстракции, который обрабатывает логику более высокого уровня и затем соответствующим образом вызывает мутации
Мутации:
Can update the state. (Having the Authorization to change the state).
Действия:
Actions are used to tell "which mutation should be triggered"
В Redux Way
Mutations are Reducers Actions are Actions
Почему Оба?
Когда приложение растет, кодирование и линии будут увеличиваться, тогда вам придется обрабатывать логику в действиях, а не в мутациях, потому что мутации являются единственным полномочием изменять состояние, оно должно быть чистым, насколько это возможно.
1. Из документов:
Действия аналогичны мутациям, причем различия заключаются в следующем:
- Вместо того, чтобы мутировать состояние, действия совершают мутации.
- Действия могут содержать произвольные асинхронные операции.
Действия могут содержать асинхронные операции, но мутация не может.
2. Мы вызываем мутацию, мы можем напрямую изменить состояние. и мы также можем в действии изменить состояния следующим образом:
actions: {
increment (store) {
// do whatever ... then change the state
store.dispatch('MUTATION_NAME')
}
}
Действия предназначены для обработки других вещей, мы можем делать много вещей там (мы можем использовать асинхронные операции), а затем изменять состояние путем мутаций отправки там.
Потому что нет состояния без мутаций! При совершении - выполняется часть логики, которая изменяет состояние в обозримом режиме. Мутации - это единственный способ установить или изменить состояние (поэтому нет прямых изменений!), И, более того, они должны быть синхронными. Это решение управляет очень важной функциональностью: мутации регистрируются в devtools. И это обеспечивает отличную читаемость и предсказуемость!
Еще одна вещь - действия. Как было сказано, действия совершают мутации. Поэтому они не меняют магазин, и им не нужно синхронно. Но они могут управлять дополнительной частью асинхронной логики!
Может показаться ненужным иметь дополнительный уровень actions только для вызова mutations, например:
const actions = {
logout: ({ commit }) => {
commit("setToken", null);
}
};
const mutations = {
setToken: (state, token) => {
state.token = token;
}
};
Итак, если вызывающие actions вызывают logout, почему бы не вызвать саму мутацию?
Вся идея действия заключается в том, чтобы вызвать несколько мутаций внутри одного действия или сделать Ajax-запрос или любую другую асинхронную логику, которую вы можете себе представить.
Мы можем в конечном итоге иметь действия, которые делают несколько сетевых запросов и в конечном итоге вызывают много разных мутаций.
Поэтому мы стараемся максимально использовать сложность нашего Vuex.Store() в наших actions и это делает наши mutations, state и getters более чистыми и прямыми и соответствует типу модульности, который делает такие библиотеки, как Vue и React популярными.