Data communication

First of all, we usually talk about data passing, component communication and so on, which I think can be divided into two scenarios:

  • Between pages

  • Between components and components

Communication plan

Regardless of the scenario, there are generally five options for data communication when using Vue.

  1. vuex

  2. storage

  3. props

  4. event

  5. URL queryString

Select communication scheme

What do we generally consider when choosing a communication scheme, such as determining how a list page passes the ID of each item to a detail page? Do you prefer vuex or sessionStorage?

In general, we should consider the following questions:

  1. Whether the page can be refreshed

  2. Whether the page is shareable (or whether the URL is RESTful)

  3. After the data is updated, whether all components that use this data need to respond to the update

Analysis of the

Let’s first talk about ‘communication scenarios between pages’. First of all, we can choose from the 5 schemes above:



vuex, storage, URL queryString.
Copy the code

Note: Page communication scenarios don’t require real-time responses, because even if the next page does have real-time responses, you won’t be able to see them, so focus on ‘refresh’ and ‘share’.

Vuex: cannot refresh, cannot share Storage: cannot share URL: Can refresh, can share

In this case, the URL queryString approach is the best choice in the ‘page traffic scenario’, but I still have my doubts:

  1. I always think it’s a bad thing to expose the jump information to the user; (Psychological problems can be overcome)

  2. Url length limits; It doesn’t matter, 2K, no matter how you pass it, I don’t think you will exceed 2K, right

  3. The URL needs to be concatenated, is this concatenation troublesome? It’s not too much trouble, just object to string.

  4. Each page will need to parse the queryString as it enters, adding to the level of trouble that mixins can handle as well. Aggregation to mixins, and not necessarily many.

So we can choose ‘URL queryString’ as the communication scheme in’ Page and page Communication scenario ‘. You can use it like this in the future:

For example, the list page to jump to the details page with an ID



    this.$router.push({
        path: 'detail'.query: {
            id
        }
    })Copy the code

Your URL will always look like this:



https://abc.com# / /? id=123
Copy the code

Note: if you can’t refresh and share your page, you can choose between the three options.

Key: The url queryString method has a problem that cannot be solved:



From the details page to the order page, the item information is brought in via queryString, assuming the URL looks like this:order/? Goods = XXX The goods= XXX order page has a receiving address bar. Click to enter the editing page of the address. The url will not have parameterseditThe address edit page has a save button that returns you to the order pageorder/
Copy the code

So, the URL queryString is missing.

My current solution: For multi-entry pages like this, be sure to save queryString the first time you enter it. And make the following judgments:



if (// queryString) {
    // use queryString
} else {
    // use storage
}
Copy the code

But it still doesn’t work to go from the address edit page back to the order page, where the user shares the order page, which is bound to be the wrong thing to share.

Now let’s talk about the five options above ‘component-to-component communication scenarios’. You can choose vuex, Event, props, and Storage

Vuex can’t refresh Event, props can refresh Can share Storage Can’t share & Real-time.

Explanation: Vuex still can’t refresh here because if you use a state that is set by another page and not already in init, refresh the lost value. The functions of the event and props are anti-refresh and anti-share because these functions take effect when the program is running and can be updated in real time. Storage has an event when it is stored, but it is too trick.

So we’re going to say Event, props?

Component communication can be divided into two types, parent and child, and peer.

Parent: props props: $emit(event)

So this is ‘props down, events up’;

$refs. XXX parent: this.$parent. XXX parent: this

Also: Custom V-Model

Also: Let props be an object.

Peer: event-bus.

So that’s it? Nothing? Well, that’s it.

thinking

  1. Not all components should be considered in vuEX application scenarios. Data transfer between routes should be via VUEX. When two options exist, there is only one reason to choose VUEX:



    Reactive state is requiredCopy the code

    why?



    Because although vuex has auxiliary functions, it still has to be defined. And it literally died as soon as it refreshed the page.Copy the code

  2. Vuex loss can be avoided by listening to the beforeUnload event, where state is cached and then recovered at the onload event.

  3. There is no need to pursue a unified communication method for the whole project. In theory, if you don’t think about refreshing and sharing, use Vuex for the whole project, nothing will happen.

  4. Vuex is state management, not a place to store constants.