Vue.js 2.0 state management

Vue.js 2.0 state management

The official implementation of flux state management

As multiple states spread across many components and interactions, the complexity of large applications often grows. T o solve this problem, Vue provides vuex: We have an Elm-inspired state management library. vuex is even integrated into vue-devtools for time travel without configuration.

React's developers should refer to the following information

If you're a developer from React, you might be concerned about the difference between vuex and redux, the most popular Flux implementation in the React ecosystem. R edux doesn't actually sense the view layer, so it can be easily used with Vue with some simple bindings. T he difference with vuex is that it is designed specifically for vue applications. This allows it to integrate better with vue while providing a simple API and an improved development experience.

Simple state management starts

Often overlooked is the actual source of the original data object in the Vue app - when accessing the data object, a Vue instance is simply proxy access. So, if you have a state that needs to be shared between multiple instances, you can simply do so by maintaining one copy of the data:

const sourceOfTruth = {}
const vmA = new Vue({
  data: sourceOfTruth
})
const vmB = new Vue({
  data: sourceOfTruth
})

Now when sourceOfTruth changes, both vmA and vmB will automatically update the views that reference them. E ach instance of the sub-components is also accessed through this.$root.$data.30. N ow we have the only real source, but debugging can be a nightmare. At any time, any part of our application, after any data changes, will not leave a record of the changes.

To solve this problem, we use a simple store pattern:

var store = {
  debug: true,
  state: {
    message: 'Hello!'
  },
  setMessageAction (newValue) {
    this.debug && console.log('setMessageAction triggered with', newValue)
    this.state.message = newValue
  },
  clearMessageAction () {
    this.debug && console.log('clearMessageAction triggered')
    this.state.message = 'action B triggered'
  }
}

It is important to note that all changes to state in the store are managed in the action of the store itself. T his centralized state management makes it easier to understand what type of mutation will occur and how they are triggered. When an error occurs, we now also have a log that records what happened before the bug.

In addition, each instance/component can still own and manage its own private state:

var vmA = new Vue({
  data: {
    privateState: {},
    sharedState: store.state
  }
})
var vmB = new Vue({
  data: {
    privateState: {},
    sharedState: store.state
  }
})

It is important to note that you should not replace the original state object in action - components and stores need to reference the same shared object before mutation can be observed.

Then we went on to extend the convention that the component does not allow direct modification of state that belongs to the store instance, but 2 should perform action to distribute the (dispatch) event notification store to change, and we finally reached the Flux schema. The benefit of this convention is that we are able to record state changes that occur in all stores, while implementing advanced debugging tools that can record changes (mutation), save status snapshots, and historical rollback/time travel.

Having said a lap is actually back to vuex, if you've read it, maybe try it!