Shulou(Shulou.com)06/01 Report--

In order to solve the problem of how to manage the sharing state in Vue 3, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Writing large applications can be a challenge. Using shared state in Vue3 applications can solve the complexity of the project. There are many common state solutions, and I'll delve into the pros and cons of using factories, shared objects, and Vuex. I will also show you some content in Vuex5 that may change the state of our use of sharing in Vue3.

State can be difficult, but when we start a simple Vue project, it's simple as long as we keep a specific component working:

Setup () {let books: Work [] = reactive ([]); onMounted (async () = > {/ / Call the API const response = await bookService.getScienceBooks (); if (response.status = 200) {books.splice (0, books.length, .response.data.works);}}); return {books};}

This can be attractive when your project is a single page that displays data (perhaps to sort or filter the data). In this case, however, the component will get the data for each request. What if you want to keep it? At this point, state management can play a role. Because network connections are usually expensive and occasionally unreliable. Therefore, it is best to maintain some state when browsing the application.

Another problem is communication between components. Although you can communicate with child-parents directly using events and props, it can be difficult to deal with simple situations such as error blocking and busy flags when each of your views/pages is independent. For example, suppose you use a top-level control to display error and load animation:

/ / App.vue Bookcase {{error}} Loading...

If there is no effective way to deal with this state, it may recommend using a publish / subscribe system, but in fact it is more direct to share data in many cases. If you want to use shared state, what should you do? Let's take a look at some common methods.

Note: you will find the code for this section in the "main" branch of the sample project on GitHub.

Sharing status in Vue3 #

Since I migrated to Vue 3, I have completely migrated to using Composition API, and in this article I have also used TypeScript, although this is not required in the examples I have shown. Although you can share state in any way, I will show you some of the most commonly used technical models I have found, each of which has its own advantages and disadvantages, so don't treat anything I say here as unique.

Technologies include:

Factory model

Shared singleton

Vuex 4

Vuex 5.

Note: at the time of this writing, Vuex5 is still in the RFC stage, so I want you to prepare for the arrival of Vuex5, but there is no working version of this option yet.

Let's learn more about.

Factory #

Note: the code for this section is located in the "Factories" branch of the sample project on GitHub.

The factory pattern is only concerned with instances of the state you create. In this mode, you will return a function that is very similar to the start function in Composition API. You will create a scope and build the components you are looking for. For example:

Export default function () {const books: Work [] = reactive ([]); async function loadBooks (val: string) {const response = await bookService.getBooks (val, currentPage.value); if (response.status = 200) {books.splice (0, books.length, .response.data.works);} return {loadBooks, books};}

You can ask the factory to create the part of the object you need:

/ / In Home.vue const {books, loadBooks} = BookFactory ()

If we add an isBusy tag to show when the network request occurs, the above code will not change, but you can decide where to display the isBusy:

Export default function () {const books: Work [] = reactive ([]); const isBusy = ref (false); async function loadBooks (val: string) {isBusy.value = true; const response = await bookService.getBooks (val, currentPage.value); if (response.status = 200) {books.splice (0, books.length, .response.data.works);} return {loadBooks, books, isBusy};}

In another view (vue?) You can just isBusy tags without knowing how the rest of the factory works:

/ / App.vueexport default defineComponent ({setup () {const {isBusy} = BookFactory (); return {isBusy}},})

But you may have noticed a problem; every time we call the factory, we get new instances of all objects. Sometimes you want the factory to return a new instance, but in our case we are talking about shared state, so we need to move the creation outside the factory:

Const books: Work [] = reactive ([]); const isBusy = ref (false); async function loadBooks (val: string) {isBusy.value = true; const response = await bookService.getBooks (val, currentPage.value); if (response.status = 200) {books.splice (0, books.length, .response.data.works);} export default function () {return {loadBooks, books, isBusy};}

Now, the factory has given us a shared instance or a singleton. While this mode works, it can be confusing to return a function that does not create a new instance every time.

Because the underlying objects are marked as const, they cannot be replaced (nor can they break the nature of the singleton). So this code should report an error:

/ / In Home.vue const {books, loadBooks} = BookFactory (); books = []; / / Error, books is defined as const

Therefore, it is important to ensure that the mutable state can be updated (for example, using books.splice () instead of setting books). Another way to handle this is to use a shared instance

Shared instance #

The code in this section is in the "Sharedstate" branch of the sample project on GitHub.

If you use shared state, it's best to be aware of the fact that status is a singleton. In this case, it can be imported as a static object. For example, I like to create an object that can be imported as a responsive object:

Export default reactive ({books: new Array (), isBusy: false, async loadBooks () {this.isBusy = true; const response = await bookService.getBooks (this.currentTopic, this.currentPage); if (response.status = 200) {this.books.splice (0, this.books.length, .response.data.works);} this.isBusy = false;}})

In this case, you just need to import the object (in this case I call it a store):

/ / Home.vueimport state from "@ / state"; export default defineComponent ({setup () {/ /... OnMounted (async () = > {if (state.books.length = 0) state.loadBooks ();}); return {state, bookTopics,};},})

Then it's easy to bind to the state:

As with other modes, you can share this instance between views:

/ / App.vueimport state from "@ / state"; export default defineComponent ({setup () {return {state};},})

It can then be bound to the same object (whether it is the parent page of Home.Vue) or routed to another page:

Bookcase Loading...

Whether using factory mode or sharing instances, they all have a common problem: variable state. Unexpected side effects can occur when you don't want binding or code to change state. In the simple example I used in this article, it's not that complicated, so don't worry. But as the application you build gets bigger and bigger, you will need to consider the state change more carefully. That's when Vuex can lend a helping hand.

VUEX 4 #

The code in this section is located in the "Vuex4" branch of the sample project on GitHub.

Vuex is the status manager for vue. It is built by the core team, but it is managed as a separate project. The purpose of Vuex is to separate the state from the state execution operation. All state changes must go through Vuex, which means it's more complex, but you can prevent unexpected state changes.

The idea of Vuex is to provide a predictable state management process. View flow Actions,Actions in turn uses Mutations to change the state, thus updating the view. By limiting the flow of state changes, you can reduce the side effects of changing the state of an application; this makes it easier to build larger applications. Vuex has a learning curve, but with this complexity, you can achieve predictability.

In addition, Vuex supports program debugging (through Vue Tools) to handle state management, including a feature called time-travel. This allows you to view the history of the status and move back and forth to see how it affects the application.

Sometimes, Vuex is also important.

To add it to your Vue 3 project, you can add the package to the project:

> npm i vuex

Alternatively, you can add it using Vue CLI:

> vue add vuex

By using CLI, it will create an initial starting point for your Vuex Store, otherwise you will need to manually connect it to the project. Let's see how this works.

First, you need to create a state object using the createStore function of Vuex:

Import {createStore} from 'vuex'export default createStore ({state: {}, mutations: {}, actions: {}, getters: {}})

As you can see, Store needs to define multiple attributes. State is just a list of data that you want to grant access to your application:

Import {createStore} from 'vuex'export default createStore ({state: {books: [], isBusy: false}, mutations: {}, actions: {}})

Note that state should not be wrapped in ref or reactive. The data here is the same as the shared data type we use in the shared instance or factory. This store will be used as a singleton in your application, so the data in the state will also be shared.

Then, let's take a look at actions. Actions is a console that allows you to change data in state, for example:

Actions: {async loadBooks (store) {const response = await bookService.getBooks (store.state.currentTopic, if (response.status = 200) {/ /...}

Actions passes an instance of store so that you can get the status and other operations. Usually, we only deconstruct what we need:

Actions: {async loadBooks ({state}) {const response = await bookService.getBooks (state.currentTopic, if (response.status = 200) {/ /...}

The last one is Mutations. Mutations is a function that can change the state. Only Mutations can affect the state. In this example, we need Mutations to change the state:

Mutations: {setBusy: (state) = > state.isBusy = true, clearBusy: (state) = > state.isBusy = false, setBooks (state, books) {state.books.splice (0, state.books.length, .books);}}

The Mutation function always passes in the state object so that you can change the state. In the first two examples, you can see that we explicitly set the state. But in the third example, we passed in the state of set. When calling mutation, mutation always receives two parameters: state and argument.

To call mutation, you need to use the commit function in store. In our example, I just added it to the deconstruction:

Actions: {async loadBooks ({state, commit}) {commit ("setBusy"); const response = await bookService.getBooks (state.currentTopic, if (response.status = 200) {commit ("setBooks", response.data);} commit ("clearBusy");}}

You will see here how commit requires the naming of action. There are some tricks to make it more than just a magic string. But I'm skipping them now. This magic string is one of the ways to limit the use of Vuex.

While using commit may seem like an unnecessary wrapper, keep in mind that Vuex won't let you change your state except within mutation, so only through commit calls.

You can also see that the call to setBooks takes a second argument. This is the second parameter that calls mutation. If you need more information, you need to package it into a parameter (another limitation of Vuex currently). Suppose you need to insert a book into the book list, you can call it this:

Commit ("insertBook", {book, place: 4}); / / object, tuple, etc.

Then you can solve what you need:

Mutations: {insertBook (state, {book, place}) = > / /...}

Is it elegant? Not really, but it works.

Now that our action has dealt with mutations, we need to be able to use Vuex storage in our code. There are two ways to get store. First, by registering store with an application such as main.ts/js, you will have access to a centralized store that you can access anywhere in the application:

/ / main.tsimport store from'. / store'createApp (App) .use (store) .use (router) .mount ('# app')

Note that this is not adding Vuex, but the store you are actually creating. Once added, you only need to call useStore to get the store object:

Import {useStore} from "vuex"; export default defineComponent ({components: {BookInfo,}, setup () {const store = useStore (); const books = computed (() = > store.state.books); / /.

This works well, but I prefer to import store directly:

Import store from "@ / store"; export default defineComponent ({components: {BookInfo,}, setup () {const books = computed (() = > store.state.books); / /.

Now that you have access to the store object, how do you use it? For state, you need to wrap them with computational functions to change them and pass them on to your binding:

Export default defineComponent ({setup () {const books = computed (() = > store.state.books); return {books};},})

To call actions, you need to call the dispatch method:

Export default defineComponent ({setup () {const books = computed (() = > store.state.books); onMounted (async () = > await store.dispatch ("loadBooks")); return {books};},})

Parameters that Actions can add after the name of the method. Finally, to change the state, you need to call commit as we did in Actions. For example, I have a paging property in store, and then I can change the state using commit:

Const incrementPage = () = > store.commit ("setPage", store.state.currentPage + 1); const decrementPage = () = > store.commit ("setPage", store.state.currentPage-1)

Note that this call may throw an exception (because you cannot change the state manually):

Const incrementPage = () = > store.state.currentPage++; const decrementPage = () = > store.state.currentPage--

This is where Vuex is really powerful, where we want to control state changes without causing further errors in the development process.

You may be overwhelmed by the way there are a lot of state changes in Vuex, but it does help manage states in larger and more complex projects. I won't say you need it in every case, but there will be some large projects that will help you in general.

This is where Vuex 5 aims to simplify the way Vuex works in TypeScript (and JavaScript projects in general). Let's see how it works after the next release.

VUEX 5 #

Note: the code for this section is located in the "Vuex5" branch of the sample project on GitHub.

At the time of this writing, Vuex 5 has not yet appeared. This is a RFC (ask for advice). That's the plan. Is the starting point of the discussion. So many of the things I've explained here may change. But in order to prepare you for the changes in Vuex, I want you to know where it is going. Therefore, the code associated with this example is not generated.

The basic concepts of how Vuex works have not changed from the beginning. With the introduction of Vue 3, Vuex 4 was created primarily to allow Vuex to work on new projects. But the team is trying to find the real pain points of Vuex and address them. To that end, they are planning some important changes:

There is no more mutations: actions can change the mutation (maybe any one).

Better TypeScript support.

Better multi-store function.

So how does it work? Let's start by creating a store:

Export default createStore ({key: 'bookStore', state: () = > ({isBusy: false, books: new Array ()}), actions: {async loadBooks () {try {this.isBusy = true; const response = await bookService.getBooks (); if (response.status = = 200) {this.books = response.data.works;} finally {this.isBusy = false }}, getters: {findBook (key: string): Work | undefined {return this.books.find (b = > b.key = key);})

The first thing to see is that each store now needs its own key. This allows you to retrieve multiple store. Next, you'll notice that the state object is now a factory (for example, returning from a function, not created at parsing time). There is no mutations part. Finally, inside actions, you can see that the state we are accessing is only the attribute that this points to. You no longer need to pass state to commit Actions. This not only helps simplify development, but also makes it easier for TypeScript to infer types.

To register Vuex with your application, you will register Vuex instead of your global store:

Import {createVuex} from 'vuex'createApp (App) .use (createVuex ()) .use (router) .mount (' # app')

Finally, to use store, you will import store and create an instance of it:

Import bookStore from "@ / store"; export default defineComponent ({components: {BookInfo,}, setup () {const store = bookStore (); / / Generate the wrapper / /.

Note that what is returned from the store is a factory object that returns an instance of the store no matter how many times you call the factory. Returns just an actions, state, and getters object (with type information) with a single class behavior:

OnMounted (async () = > await store.loadBooks ()); const incrementPage = () = > store.currentPage++;const decrementPage = () = > store.currentPage--

You will see here that state (such as currentPage) is just a simple property. Actions, such as loadBooks, is just a function. In fact, the store you use here is a side effect. You can treat the Vuex object as an object and continue to work. This is a major improvement for API.

Another important change to point out is that you can also use syntax similar to Composition API to generate your store:

Export default defineStore ("another", () = > {/ / State const isBusy = ref (false); const books = reactive (new Array ≷ Work > ()); / / Actions async function loadBooks () {try {this.isBusy = true; const response = await bookService.getBooks (this.currentTopic, this.currentPage); if (response.status = 200) {this.books = response.data.works;} finally {this.isBusy = false }} findBook (key: string): Work | undefined {return this.books.find (b = > b.key = key);} / / Getters const bookCount = computed (() = > this.books.length); return {isBusy, books, loadBooks, findBook, bookCount}})

This allows you to build Vuex objects the same way you use Composition API build views, and it's arguably simpler.

One of the main drawbacks of this new design is the loss of state immutability. There has been discussion about being able to enable this feature (for development only, like Vuex 4), but no consensus has been reached on its importance. Personally, I think this is the main thing about Vuex, but we have to see how it works.

This is the answer to the question about how to manage the shared state in Vue 3. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.