[Vue3-State Management] (How to access the responsive data of the root component/subcomponent outside the component) How to uniformly manage responsive data among multiple components

Often overlooked,  data the actual source of reactive objects in a Vue application - a component instance is simply a proxy for access when accessing data objects. So, if you have a piece of state that needs to be shared between multiple instances, you can use a  reactive  method to make the object reactive.

const { createApp, reactive } = Vue
const sourceOfTruth = reactive({
  message: 'Hello'
})

const appA = createApp({
  data() {
    return sourceOfTruth
  }
}).mount('#app-a')

const appB = createApp({
  data() {
    return sourceOfTruth
  }
}).mount('#app-b')

<div id="app-a">App A: {
   
   { message }}</div>

<div id="app-b">App B: {
   
   { message }}</div>

Now when  sourceOfTruth a change occurs, appA and  appB both will automatically update their views. While now we have a source of truth, debugging would be a nightmare. Any part of the application can change any data at any time without leaving a record of what was changed.

const appB = createApp({
  data() {
    return sourceOfTruth
  },
  mounted() {
    sourceOfTruth.message = 'Goodbye' // both apps will render 'Goodbye' message now
  }
}).mount('#app-b')

To solve this problem, a simple  store pattern can be adopted :

const store = {
  debug: true,

  state: reactive({
    message: 'Hello!'
  }),

  setMessageAction(newValue) {
    if (this.debug) {
      console.log('setMessageAction triggered with', newValue)
    }

    this.state.message = newValue
  },

  clearMessageAction() {
    if (this.debug) {
      console.log('clearMessageAction triggered')
    }

    this.state.message = ''
  }
}

It should be noted that all state changes in the store are managed in the action of the store itself. This centralized state management makes it easier to understand what types of changes will occur and how they are triggered. When a bug occurs, there is now also a log of what happened before the bug.

Additionally, each instance/component can still own and manage its own private state:

<div id="app-a">{
   
   {sharedState.message}}</div>

<div id="app-b">{
   
   {sharedState.message}}</div>

const appA = createApp({
  data() {
    return {
      privateState: {},
      sharedState: store.state
    }
  },
  mounted() {
    store.setMessageAction('Goodbye!')
  }
}).mount('#app-a')

const appB = createApp({
  data() {
    return {
      privateState: {},
      sharedState: store.state
    }
  }
}).mount('#app-b')

State Management

TIP

It is important to note that you should not replace the original state object in the action - the component and the store need to reference the same shared object for changes to be observed.

As we further expand the agreement, that is, components are not allowed to directly change the state belonging to the store instance, but should execute actions to dispatch (dispatch) events to notify the store to change, and finally reached the Flux  architecture  . The advantage of this agreement is that it can record the state changes that occur in all stores, and at the same time implement advanced debugging tools that can record changes, save state snapshots, and roll back history/time travel.

 

Guess you like

Origin blog.csdn.net/weixin_42117463/article/details/121916938