Front-end state management (Part 2)

Preface:

Continuing from the previous article, Front-end State Management (Part 1), I didn’t expect so many readers to pay so much attention to it. Thank you all for your support and suggestions. I am just expressing my personal opinions and some of my own thoughts, which may not be comprehensive enough. The example of using Vue is just a guide and Vue also has a high level of attention. Some friends want to hear other solutions besides Vuex. Today we will start with Redux and gradually expand (just like the title).

1. Redux

As a member of the React family, Redux attempts to provide a predictable state management mechanism for React applications. Like most state management solutions, the idea of ​​Redux is also a publish-subscribe model. Let’s take the library as an example to briefly understand Redux.

The basic operations of Redux are roughly as follows:

• Store (Librarian)
• State (Book)
• Action (Book borrowing list)
• store.dispatch (submit borrowing list)
• Reducer (Packaging Books)
• store.subscribe (receive books)

1.1. Store (librarian)

Store can be regarded as a container, and there is only one Store in the entire application. It's like if you want to borrow a book you can only go to the librarian.

import { createStore } from 'redux'
const store = createStore(reducer);

1.2. State (Book)

For State , it can only be changed through Action (that is, you can only borrow books by submitting a borrowing form), and the value in State should not be modified directly.

Use store.getState() to get state .

import { createStore } from 'redux'
const store = createStore(reducer)
store.getState()

1.3. Action (Book Borrowing List)

What if you want to borrow a book? Of course, you need to submit a book borrowing list to the administrator. Then the user cannot access State and can only operate through the View (such as clicking a button, etc.). That is, the change of State corresponds to the change of View , so the View needs to submit an Action to notify State change. (Submitting the borrowing list to the administrator will lead to a series of other operations)

Action is a custom object, in which the type attribute is the agreed operation to be performed.

const action = {
    type: 'click',
    info: 'Submit borrowing list'
}

1.4、store.dispatch (submit borrowing list)

store.dispatch is the only way for View to send an Action. It accepts an Action object (i.e. submitting a borrowing list) and simply gives the list information to the librarian, who then searches for the corresponding books based on the list.

store.dispatch(action)

1.5. Reducer (Packaging Books)

After Store receives an Action , it must give a new State so that the View will change, and the calculation process of the new State is completed by Reducer . (Once you have received the order, pack your books into bags, etc.)

Reducer is a custom function that accepts Action and current State as parameters and returns a new State.

const reducer = (state, action) => {
    return `action.info: ${state}` // => Submit borrowing list: Dream of the Red Chamber}

store.subscribe (receive books)
Once the State changes, store.subscribe() will listen to it and automatically update the View.

const unsubscribe = store.subscribe(() => {
  render() {
    // Update the view 
  }
})
// You can also unsubscribe (listen)
unsubscribe()

summary:

I believe that students who have just come into contact with Redux will find Redux rather complicated, which is also related to his idea: everything in Redux should be certain.

Although it is still impossible to make everything deterministic in Redux (such as asynchrony) , most parts should be guaranteed to be deterministic, including:

• View rendering is deterministic
• The reconstruction of the state is deterministic
  

As for why we should do this, I have already mentioned it in the previous article. Its importance lies in: facilitating application testing, error diagnosis and Bug fixing.

2. Purpose of state management

In fact, the most common scenario for most programmers to use Redux is to return to page B from page A and need to save the status of page B.

If the project is not large, would using Redux or Vuex seem a bit large? We know that Vue provides keep-alive to allow us to cache the current component, which can solve the above scenario.

But unfortunately there is no keep-alive in React like in Vue. The common solution in the community is to modify the routing, but this modification is too invasive to the project and difficult to maintain. In addition, the routing hook is also cancelled in react-router v5 . Therefore, it is a good idea to encapsulate a function yourself for small projects. (Of course you can use Redux if you want, we are just exploring more ways)

Let’s use the library as an example. Now there is a library management system. When you jump from the list page (list) to detail page (detail), you need to save the status of the list page (such as the status of the search bar, etc.).

Assuming that the technology stack you use is ( react + antd ), write a simple and rough one by hand (the core is to use context to transfer data across components):

//KeepAlive.js
export default function keepAliveWrapper() {
  return function keepAlive(WrappedComponent) {
    return class KeepAlive extends WrappedComponent { // ps
      constructor(props) {
        super(props)
        // do something ...
      }

      componentDidMount() {
        const {
          keepAlive: { fieldsValue },
        } = this.context
        // do something ...
        super.componentDidMount()

      }

      render() {
        // do something ...
        return super.render()
      }
    }
  }
}

Here is why we need to inherit the original component （// ps）

If the conventional writing method returns a class component ( class KeepAlive extends React.Component ), it is essentially a nested parent-child component. The life cycle of the parent and child components will be executed in order, so every time you return to the list page to get the status, it will be rendered twice. This is because the parent component returned by HOC calls the method of the original component, which causes the list page to be requested twice and rendered twice.

If HOC (high-order component) inherits from the original component, two life cycles will not be executed alternately, which solves this problem well.

// main.jsx root component import React from 'react'

const appContext = React.createContext()

class App extends React.Component {
    constructor(props) {
        super(props)
        this.state = {
          keepAlive: {}, // Cache object isCache: false, // Whether to cache fieldsValue: {} // Cache form value }
    }
    componentDidMount() {
        // Initialize const keepAlive = {
          isCache: this.state.isCache,
          toggle: this.toggleCache.bind(this),
          fieldsValue: this.state.fieldsValue,
        }
        this.setState({ keepAlive })
    }
    // Here is a method to clear the state to prevent rendering warnings (you can't set fields before render ...)
    // For example, list1 => list1/detail => list2 needs to put the jump in the following callback and clear the status toggleCache(isCache = false, payload, callback) {
        const { fieldsValue = null } = payload
        const keepAlive = {
          isCache,
          fieldsValue,
          toggle: this.toggleCache.bind(this),
        }
        const fn = typeof callback === 'function' ? callback() : void 0
        this.setState(
          {
            keepAlive,
          },
          () => {
            fn
          }
        )
    }
    render() {
        const { keepAlive } = this.state
        <appContext.Provider value={{ keepAlive }}>
            // your routes...
        </appContext.Provider>
    }

}

As for why we don’t use context directly, but encapsulate an extra layer of keepAlive , it is to unify the processing context . By using the concise writing method of decorator （@keepAlive） in the component header, you will immediately know that this is a cached component (for easy reading and maintenance).

// import React from 'react' when using it on the page
import keepAlive from '../keepAlive'

// keepAlive needs to be placed closest to the original component @keepAlive()
class App extends React.Component {
    constructor(props){
        super(props)
        this.state = {
            // init something...
        }
    }
    componentDidMount() {
        // do something...
        if(this.context.keepAlive.fieldsValue) {
            const { tableList } = this.context.keepAlive.fieldsValue
            console.log('Cached:',tableList) // Cache: ['1', '2']
        }
    }
    // View details detail = () => {
        this.context.keepAlive.fieldsValue = {
            tableList: ['1', '2']
        }
        // jump...
    }
    // When you need to jump across the first-level route, such as list1 => list1/detail (the following method should be in the details page) => list2, you need to handle the warning toList2 = () => {
        this.context.keepAlive.toggle(false, {}, () => {
            // jump...
        })
    }
}

In the above, decorator writing is used. To put it simply, you need to configure the following babel before you can use it~

npm install -D @babel/plugin-proposal-decorators

Configure in jsconfig.json (create a new one if it doesn’t exist):

{
    "compilerOptions": {
        "experimentalDecorators": true
    },
    "exclude": [
        "node_modules",
        "dist"
    ]
}

Configure in .babelrc:

{
    "plugins": [
        "@babel/plugin-proposal-decorators",
        {
            "legacy": true
        }
    ]
}

The above method is more suitable for the scenario just mentioned (returning from page A to page B requires saving the status of page B). Some people say that you might as well use Redux or Mobx . When jumping across routes, you must manually clear the status to prevent warnings. . . Different people have different opinions. The fact that you have encapsulated it yourself shows that you have done some research on it. No matter how easy or difficult it is, isn't programming itself about continuous exploration? Haha. Even though what you write may not be good enough or something, just accept criticism humbly. After all, there are many talented people out there.

Summarize:

This is the end of this article about front-end status management. For more content related to front-end status management, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!

Review of the previous article: A brief discussion on front-end state management (Part 1)