Vuex Action vs Mutations

Question

Dans Vuex, quelle est la logique d'avoir à la fois des "actions" et des "mutations" ?

Je comprends la logique qui veut que les composants ne puissent pas modifier l'état (ce qui semble intelligent), mais le fait d'avoir à la fois des actions et des mutations donne l'impression que vous écrivez une fonction pour déclencher une autre fonction, pour ensuite modifier l'état.

Quelle est la différence entre les "actions" et les "mutations", comment fonctionnent-elles ensemble, et surtout, je suis curieux de savoir pourquoi les développeurs de Vuex ont décidé de procéder de cette façon ?

Answer 1

Question 1 : Pourquoi les développeurs de Vuejs ont-ils décidé de procéder de cette manière ?

Réponse :

1. Lorsque votre application devient grande, et que plusieurs développeurs travaillent sur ce projet, vous constaterez que la "gestion de l'état" (en particulier l'"état global"), deviendra de plus en plus compliquée.
2. La méthode Vuex (tout comme Redux dans react.js ) offre un nouveau mécanisme de gestion de l'état, de conservation de l'état, et de "sauvegarde et suivi" (ce qui signifie que chaque action qui modifie l'état peut être suivie par outil de débogage:vue-devtools )

Question 2 : Quelle est la différence entre "action" et "mutation" ?

Voyons d'abord l'explication officielle :

Des mutations :

Les mutations Vuex sont essentiellement des événements : chaque mutation a un nom et un gestionnaire.

import Vuex from 'vuex'

const store = new Vuex.Store({
  state: {
    count: 1
  },
  mutations: {
    INCREMENT (state) {
      // mutate state
      state.count++
    }
  }
})

Les actions : Les actions sont simplement des fonctions qui envoient des mutations.

// 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)
}

Voici mon explication de ce qui précède :

• mutation es el seul moyen pour modifier l'état
• mutation ne se soucie pas de la logique de l'entreprise, il se soucie juste de "l'état".
• action est une logique d'entreprise
• action peut commettre plus d'une mutation à la fois, il ne fait qu'implémenter la logique métier, il ne se préoccupe pas des changements de données (qui sont gérés par mutation)

Answer 2

Les mutations sont synchrones, tandis que les actions peuvent être asynchrones.

Pour le dire autrement : vous n'avez pas besoin d'actions si vos opérations sont synchrones, sinon mettez-les en œuvre.

Answer 3

Je pense que la réponse TLDR est que les mutations sont destinées à être synchrones/transactionnelles. Donc, si vous devez exécuter un appel Ajax ou tout autre code asynchrone, vous devez le faire dans une action, puis valider une mutation après, pour définir le nouvel état.

Answer 4

Selon le docs

Actions sont similaires à mutations les différences étant que :

• Au lieu de en mutation l'État, actions commettre mutations.
• Actions peut contenir des asynchrone opérations.

Considérez l'extrait suivant.

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.
    }
  }
})

Gestionnaires d'action( incrémenter ) reçoit un objet contextuel qui expose le même ensemble de méthodes et de propriétés sur l'instance du magasin. méthodes/properties sur l'instance de magasin, de sorte que vous pouvez appeler context.commit pour valider une mutation, ou accéder à l'état et aux getters via context.state et context.getters

Answer 5

Clause de non-responsabilité - Je viens juste de commencer à utiliser Vuejs et je ne fais qu'extrapoler l'intention de conception.

Le débogage par machine à remonter le temps utilise des instantanés de l'état, et montre une chronologie des actions et des mutations. En théorie, nous aurions pu avoir juste actions à côté d'un enregistrement de setters et getters d'état pour décrire de manière synchrone la mutation. Mais alors :

• Nous aurions des entrées impures (résultats asynchrones) à l'origine des setters et getters. Cela serait difficile à suivre logiquement et différents setters et getters asynchrones pourraient interagir de manière surprenante. Cela peut encore se produire avec mutations mais nous pouvons alors dire que la transaction doit être améliorée plutôt que d'être une condition de course dans les actions. Les mutations anonymes à l'intérieur d'une action pourraient plus facilement faire resurgir ce genre de bogues car la programmation asynchrone est fragile et difficile.
• Le journal des transactions serait difficile à lire car il n'y aurait pas de nom pour les changements d'état. Il ressemblerait beaucoup plus à du code et serait moins anglais, sans les groupements logiques des mutations.
• Il pourrait être plus délicat et moins performant d'instrumenter l'enregistrement de toute mutation sur un objet de données, contrairement à la situation actuelle où il existe des points de différence définis de manière synchrone - avant et après l'appel de la fonction de mutation. Je ne suis pas sûr de l'importance du problème.

Comparez le journal des transactions suivant avec les mutations nommées.

Action: FetchNewsStories
Mutation: SetFetchingNewsStories
Action: FetchNewsStories [continuation]
Mutation: DoneFetchingNewsStories([...])

Avec un journal des transactions qui n'a pas de mutations nommées :

Action: FetchNewsStories
Mutation: state.isFetching = true;
Action: FetchNewsStories [continuation]
Mutation: state.isFetching = false;
Mutation: state.listOfStories = [...]

J'espère que vous pouvez extrapoler à partir de cet exemple la complexité supplémentaire potentielle de l'asynchronisme et de la mutation anonyme dans les actions.

https://vuex.vuejs.org/en/mutations.html

Imaginons maintenant que nous déboguons l'application et que nous regardons les journaux de mutation du devtool. Pour chaque mutation enregistrée, le devtool devra capturer un instantané de l'état "avant" et "après". Cependant, le callback asynchrone dans l'exemple de mutation ci-dessus rend cela impossible : le callback n'est pas encore appelé lorsque la mutation est validée, et le devtool n'a aucun moyen de savoir quand le callback sera effectivement appelé - toute mutation d'état effectuée dans le callback est essentiellement impossible à suivre !