Front-end state management (Part 1)

Preface:

When it comes to state management, you may immediately think of: Vuex , Redux , Flux , Mobx and other solutions. In fact, no matter which solution you choose, it seems to be a headache as long as the content increases. Maybe you have a solution that suits you or simply annotate and distinguish modules. Let’s talk about front-end state management today. If you have any good suggestions or questions, please leave a message below.

1. What is front-end state management?

For example: everyone in the library can freely enter the library to borrow and return books. If there are not many people, this method can improve efficiency and reduce the number of processes. However, once there are many people, it will easily cause confusion, the whereabouts of the books will be unclear, or even lost. Therefore, you need a librarian to specifically record the borrowing of books, that is, you have to entrust the librarian to borrow and return books for you.

In fact, most state management solutions are based on the above idea, using administrators (such as Vuex) to regulate the borrowing and returning of books in the library (data that needs to be stored in the project)

2. Vuex

The proportion of Vuex in domestic business use should be the highest. Vuex is also a product based on the Flux concept. state in Vuex can be modified. The reason is related to the operating mechanism of Vue. Vue implements two-way binding of view and data based on getter/setter in ES5 . Therefore, changes in state in Vuex can be notified to the corresponding instructions in the view through setter to implement view updates. The only way to change the state in Vuex store is to submit mutation . Let's take a library as an example:

const state = {
  book: 0
}

const mutations = {
  borrow_book(state) {
    state.book++
  }
}

//When calling store.commit('borrow_book')

What about action ? Mixing asynchronous calls with mutation can make your program very difficult to debug. How do you know which one is executed first? aciton can contain any asynchronous operation. Its usage is similar to the above and will not be described here.

In fact, I just use Vuex to briefly introduce the related usage. Everyone should be familiar with it. So what problem does Vuex solve?

• Manage shared state among multiple components.
• Global state management.
• State change tracking.
• Make state management a norm and make the code structure clearer.
  

In fact, most programmers are lazy (for the life of them), and they only want to share state among multiple components, and everything else is afterthought. The most typical example is the number of items added to the shopping cart. When one item is added, the final total is saved through Vuex records and displayed in the lower column.

Now the question is, since your purpose is just to share multiple states, why not just use Bus ?

3. Bus

Bus is actually a public Vue instance that specializes in handling emit and on events.

In fact, the Bus is very lightweight. It does not have a Dom structure, it just has instance methods.

Vue.prototype.$Bus = new Vue()

Then, you can send events via emit and receive events via on .

//Send event this.$Bus.$emit('borrow_book', 1)

// Received in any component this.$Bus.$on('borrow_book', (book) => {
    console.log(`Borrowed ${book} book`)
})

Of course, there are also operations such as off (remove) and once (listen once). If you are interested, you can search for it yourself.

How about it? Is the above much simpler than Vuex for sharing a state? In fact, it is much simpler, but this also means that it is more suitable for small and medium-sized projects. For large projects, Bus will only make you confused when tracing the changed source, and you may not even know where it has been changed.

Its working principle is the idea of ​​publishing and subscribing. Although it is very elegant and simple, Vue does not advocate this way of writing, and removed most of the related Api (emit, on, etc.) in version 3.0. In fact, we can write one by ourselves to implement the publish-subscribe mode:

class Bus {
 constructor() {
  // Collect subscription information, dispatch center this.list = {};
 }

 // Subscribe$on(name, fn) {
  this.list[name] = this.list[name] || [];
  this.list[name].push(fn);
 }

 // Publish $emit(name, data) {
  if (this.list[name]) {
                    this.list[name].forEach((fn) => {
                        fn(data);
                    });
                }
 }

 // Unsubscribe $off(name) {
  if (this.list[name]) {
   delete this.list[name];
  }
 }
}
export default Bus;

Simple, right? You just need to instantiate it and use it just like you would with Vue Bus . What? If you want to share two or three or even less states (one), then isn't it unnecessary to encapsulate a Bus ? OK, then you can use web storage .

4. Web storage

In fact, when it comes to this, storage is just a way of storing data. It has nothing to do with state management. It is just about sharing data. But since it has been mentioned, let me just say it in passing (dog head)

There are three types web storage : cookie , local storage , and session storage .

No matter which of these three, it is strongly recommended not to put sensitive information in it. It should be encrypted or contain some less important data.

Let’s briefly review the three:

loaclStorage can store data that is theoretically permanently valid. If you want to store state, it is generally recommended to put it in sessionStorage . localStorage also has the following limitations:

• The browser sizes are not uniform, and only IE versions above IE8 support the localStorage property.
• Currently, all browsers limit the value type of localStorage to string type, which requires some conversion for the JSON object type that we are more familiar with in daily life.
• localStorage is not readable in the browser's privacy mode.
• localStorage is essentially a string read. If there is a lot of storage, it will consume memory space and cause the page to become stuck.
• localStorage cannot be crawled by crawlers.

The only difference between localStorage and sessionStorage is that localStorage is permanent storage, while sessionStorage is a key-value pair in sessionStorage that will be cleared when the session ends.

localStorage itself only supports string storage, so if you store an integer, the output will be a string.

sessionStorage is basically the same as localStorage , except that the data is cleared when the session is closed.

Summarize:

No matter which solution you choose, it is the best practice to choose the one that suits your project. There is no best solution, only the solution that suits you.

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!