Front-end local state management attempts

Why is that?

With such an architecture, why can’t state management go directly to VUEX? Imagine developing it as a normal VUE project. Vuex is used for global state management. So what happens as you add more modules?

• More and more VuEX modules will be maintained.
• It is coupled to the vuEX of the root instance and depends on the global VUEX for functionality.
• With the main project there is a risk of code intrusion, logic understanding and complexity.

Another example is a component or UI framework introduced in a project, such as element-UI. It also has a relatively complex combination of components like forms and things like that, how does their state management work? It’s a black box for your project, you don’t have to think about how it needs to manage state, you just have to learn to use it. As you can see, local state management is very useful for components or modules. Local state management comes into being. We need to emulate or organize a form of local state management. In the huge project, to maintain its own side of the world.

Solution ideas

The requirements have already been generated. What are the solutions or ideas that can be implemented?

What can we learn

For state management of data, we want to maintain it locally. There are a number of ways to do this, but we have to consider the migration costs of the project itself and so on. Such as

• Copy a partial version of vuex
• Vue3 project, we can try to use the Composition API to implement a hook form of local top-level data logic file. If you are interested in this, you can refer to another article to get a feel for the idea.

Vue3 are you still using Vuex? A new idea of “functional” state management

To a sketch

Concrete implementation logic

According to the above several technical points, the code logic is roughly combed, with a simple idea, the implementation of the code is not complex, and has been applied in the business. The effect is actually much more comfortable than the original top-down, parent-to-child data flow.

Parse module, state, and mutation configurations

What is the structure of a Module in VUex

const moduleA = {
  state: () = >({... }),mutations: {... },actions: {... },getters: {... }}const moduleB = {
  state: () = >({... }),mutations: {... },actions: {... }}const store = new Vuex.Store({
  modules: {
    a: moduleA,
    b: moduleB
  }
})

store.state.a // -> moduleA status
store.state.b // -> moduleB status
Copy the code

To clarify, the requirements and configuration objects can be exactly the same, except that the resolution of actions is omitted. First of all, the first step is of course to parse state, mutations, modules in the configuration object. We need to build two trees, namely the state tree and the mutations tree, and complement the two trees through the namespace of different modules. The code, of course, is all about recursion, type determination, and error cues. The following example is the configuration of the input, and the state tree of the output, and the change method tree.

// Create a store instance based on the configuration object
const store = new myStore({
  state:() = >({
    top:0
  }),
  modules: {a: {state:() = >({
        val1:1.val2:2
      }),
      mutations: {set1(state,value){
          // We need to resolve the state in the same namespace as the current modules
          state.val1 = value
        }
      }
    }
  }
})

// The full state tree after parsing
state = {
  top:0
  a: {val1:1.val2:2}}// Complete mutations tree after analysis
mutations = {
  a: {set1:function(state,value){
      state.val1 = value
    }
  }
} 
Copy the code

The second step is data hijacking of state data. Only by data hijacking of the state tree can the use in the VUE instance be collected, and the render method of the corresponding Vue instance is executed after the data changes to update the attempt. This is also the key point of the MVVM framework. If it is a vUE stack project, super convenient, just need to update the VUE version after 2.6. I’m going to refer to this API

Vue.observable( object )

Make an object responsive. It is used internally by Vue to process objects returned by the data function. The returned object can be used directly in rendering functions and computed properties, and will trigger an update when changes occur.

The react project uses the react data hijacking mode or binding mode to manage the local state of the react project. The implementation is the same with the logic modification. After all, vuex and Redux are similar in usage and logic. The third step

Provide state data and some helper functions

• Commit The commit method is the function that we use to directly distribute status updates instead of Dispatch. When analyzing and generating the Mutations tree, we simply wrap the function and pass in the corresponding state of the namespace.

// Part of the code, recursively traverses the mutations tree, and processes the state pass in the current namespace as the first argument
const fn = mutations[key]
mutations[key] = function(. params) { fn(state, ... params) }Copy the code

• Getter The encapsulation of the getter, depending on what you want, is equivalent to the computed properties of the state tree.

Here you can see the code framework of the rough implementation

// partial vuex class Ss {constructor({state, mutations, getters, modules }) { this.state = state this.mutations = mutations this._init(modules || {}) } _init(modules) { if (typeof modules ! == 'object') {throw new Error('moudels configuration parameter is not an object')} /** * @test: none * @msg: Mutations * @param {state, mutations, actions, modules} * @return {state, mutations, actions} */ const moudelsState = getModels('state', modules) this.state = Object.assign(this.state, ... moudelsState) const moudelsMutations = getModels('mutations', modules) this.mutations = Object.assign(this.mutations, . moudelsMutations) /** * @test: none * @msg: Hijacking state content. If react is used, consider seeing what can replace * to determine the vUE version used. * @param {state} * @return {state} */ this.state = vue.Observable (this.state) /** * @test: none * @msg: Mutations ** return {*} */ handlem. call(this, this.state, this.mutations)} /** * @test: None * @msg: submit mutations through commit, so that every change of state has a unified entrance, and the process of change can be easily recorded. * @param {*} type string mutations definition path such as: 'layer.setViews' * @param {*} value * @return {*} */ commit(... res) { ... }}Copy the code

After these three steps, the framework is complete, and the simplest local state management is complete. It’s ready for use. Of course, there are still a lot of capabilities missing, such as strict mode, which only allows commit to commit changes. Exception error supplement during parsing. Add some hook functions, provide some extensible plug-in capabilities, etc. Say so much, also is to provide a thinking train of thought actually only. See more, use more, change more, slowly improve their own cognitive and business ability.