This is the fifth day of my participation in Gwen Challenge

To understand VueX, first understand what problem VueX solves? In the actual development process, we will encounter some values passed from father to child, from father to grandson, from brother to brother, etc. Of course, we can pass them layer by layer, but once the component level is very deep, data will be passed from one layer to another, and the code will not be repeated, which is not conducive to maintenance and reading. VueX is to solve this problem. Provide us with a data management pool that is needed to manage multiple components and manage data uniformly through Vuex’s API.

VueX workflow

It can be understood simply according to the following figure:

First, Vue Components dispatches different actions using different actionsType, and causes different actions to commit different mutations. Let mutations change state, and finally state changes the view through internal render.

Mutations cannot write an asynchronous method. If you write an asynchronous method, you need to write it in actions.

Thus, a rough VueX workflow is basically formed. (Don’t worry, mentally describe the diagram in your own words until you use it.)

VueX的API

Simple explanation of state, getters, Actions, mutations, modules

  • State: data of the component, which is also the data operated by VueX. It is the data used by multiple components.
  • Getters: computed, embellished data equivalent to a component.
  • Actions: the equivalent of a component’s methods asynchronous method.
  • Mutations correspond to components methods and simultaneous solutions.
  • Modules: VueX is broken up into separate modules, which can be thought of as little index.js.

VueX generally stores index.js or index.ts in the store file, and then the actual project will generally separate state, getters, actions and mutations into modules, which is convenient for independent management. However, there is no getters in each modules, it is a separate getters.js, which is uniformly retrieved.

Vuex3. x is usually new vuex.store ({… }), and vuex4.x is createStore({… })

Store ├ ─ ─ modules │ ├ ─ ─ app. Js │ ├ ─ ─ token. Js │ └ ─ ─ the user. The js ├ ─ ─ getters. Js └ ─ ─ index, js//index.js
import Vue from 'vue'
import Vuex from 'vuex'

Vue.use(Vuex)

// Import modules
import getters from './getters'
const modulesFiles = require.context('./modules'.true./\.js$/)
const modules = modulesFiles.keys().reduce((modules, modulePath) = > {
  const moduleName = modulePath.replace(/^\.\/(.*)\.\w+$/.'$1')
  const value = modulesFiles(modulePath)
  modules[moduleName] = value.default
  return modules
}, {})

const store = new Vuex.Store({
  modules,
  getters
})

export default store

Copy the code

The use of VueX

Use the above diagram again:We need to use VueX from the perspective of Vue Components in the figure:

There is a data in the state of VueX warehouse that I want to change. What way should I change it?

  • Asynchronous:

First, Vue Components needs to dispatch actions by specifying actionsType, get actions to commit mutations, and get mutations to change state. Finally, state changes the view via internal render.

<script>
export default {
  data(){
      return{... }}methods: {this.$store.dispatch('xxx')
  }
}
</script>
Copy the code
  • Does not involve asynchrony:

First, Vue Components directly go to commit mutations, then let mutations change state, and finally state changes the view via internal render.

<script>
export default {
  data(){
      return{... }}methods: {this.$store.commit('xxx')
  }
}
</script>
Copy the code

State and getters are written in computed, while Actions and mutations are written in methods

In this way, we can modify the data needed by each component in this way, without layer upon layer transfer, to achieve the effect of modification, modification everywhere, state sharing.

details

this.$store.dispatch(‘xxx’);

this.$store.commit(‘xxx’);

this.$store.getters(‘xxx’);

this.$store.state(‘xxx’);

Auxiliary function