vue summary 08 state management vuex

 

state management

Official implementation of Flux-like state management

Large applications also often grow in complexity as state is scattered across many components and interactions between components. To solve this problem, Vue provides  vuex : we have state management library inspired by Elm. vuex is even integrated into  vue-devtools for time travel debugging without configuration .

React developers please refer to the following information

If you're a React developer, you might be concerned about the differences between Vuex and  Redux  , the most popular Flux implementation in the React ecosystem. Redux isn't actually view-aware, so it can easily be used with Vue with some simple bindings . The difference with Vuex is that it's designed specifically for Vue applications. This allows for better integration with Vue, while providing a clean API and an improved development experience.

Simple state management to get started

What is often overlooked is 数据the actual source of raw objects in a Vue application - a Vue instance is simply proxy access when accessing data objects. So, if you have a piece of state that needs to be shared between multiple instances, you can do so simply by maintaining a copy of the data:

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

Now when  sourceOfTruth changes are made, vmA and  vmB both will automatically update views that reference them. Each instance of subcomponents is also accessed via  this.$root.$data . Now we have the only real source, however, debugging will be a nightmare. At any time, no part of our application will leave a record of changes after any data has been changed.

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

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

It should be noted that all state changes in the store are placed in the store's own action to manage. This centralized state management makes it easier to understand what types of mutations will happen and how they will be triggered. When a bug occurs, we now also have a log of what happened before the bug.

Additionally, 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's important to note that you shouldn't replace the original state object in the action - the component and store need to reference the same shared object for the mutation to be observable

Then we continue to extend the agreement, components are not allowed to directly modify the state belonging to the store instance, but should execute actions to dispatch events to notify the store to change, and we finally reached the  Flux  architecture. The benefit of this convention is that we can record state changes that occur in all stores, while implementing advanced debugging tools that can record mutations, save state snapshots, and rollback history/time travel.

After talking about it, it's actually back to vuex , if you've read this, maybe you can try it!