vue data delivery-I have special implementation skills

Preface

Recently I have encountered many questions about vue eventBus. I was also asked about the scope of use of vuex and eventBus when selecting technology before. So just write it briefly. There is also a special implementation solution.

There are several ways to pass data, vuex, props, eventBus and special eventBus.

vuex

If you don’t introduce it, you will look down without using it.

props

demo

Parent-child component passes values, official API, only writes a demo.

1. Parent component

<son :info="info" @update="updateHandler"/>
// data
info: 'sendToSon'
// methods
updateHandler (newVal) {
  = newVal
}

2. Subcomponents

// props
props: ['info']
// Upload value, use in a certain methodthis.$emit('update', 'got')

Parent passes value to child -->props Children passes value to parent --> child component binding event callback is defined in the parent component, and the child component triggers this event. Because it is not recommended to directly modify the props passed in by the parent component in the child component, custom events are required.

limit

Parent-child component.

eventBus

demo

Bus are imported bus instances

// bus
const bus = new Vue()
// Data Receiver Component// The current component receives the valuebus.$on('event1', (val)=>{})
// Data emitting component// The current component emits a valuebus.$emit('event1', val)

It can be seen that the essence is that a vue instance acts as a medium for event binding. It is used in all instances for data communication.

Double (multi) parties use events of the same name to communicate.

question

1. When $emit, $on must be already, otherwise the event will not be listened to, which means that there are certain requirements for the component to exist simultaneously. (Note: When switching routes, the new routing component is created first, the old routing component is then created. In some cases, you can write to these two life cycles separately, see this question).
2. $on will not be automatically unbined after the component is destroyed. If the same component is generated multiple times, the event will be bound multiple times. Then $emit will be once, and multiple responses will be required, and additional processing will be required.
3. The data is not "long-term" data and cannot be saved and only takes effect after $emit.

So is there a more applicable solution?

Special eventBus?

demo

Let’s look at the code first, the online code. Bus are imported bus instances.

// bus
const bus = new Vue({
 data () {
  return {
   // Define data   val1: ''
  }
 },
 created () {
  // Bind listening  this.$on('updateData1', (val)=>{
   this.val1 = val
  })
 }
})
// Data emitting componentimport bus from 'xx/bus'
// Trigger event that has been bound in busbus.$emit('update1', '123')
// Data Receiver Component
{{val1}}
// Use computed to receive datacomputed () {
 val1 () {
  // Depend on and return val1 in bus  return bus.val1
 }
}

different

1. Orthodox eventBus is only used to bind and trigger events, and does not care about data and does not intersect with data. This solution adds data directly to the bus instance in one step. Event listening and data addition need to be defined in advance.
2. The data receiver no longer uses $on to know the data changes, but passively receives it through the characteristics of the calculated attributes.

Problems solved

Do communication components need to exist at the same time? The data is stored on the bus, so there is no requirement.

Multiple bindings? The binding listening is on the bus and will not be bound repeatedly.

Data is only available after $emit? Use computed properties to read the value existing on the bus directly, and there is no need to trigger the event again.

Discussion

Why use computed properties

In fact, it should be why it cannot be added directly to data, such as data1: bus.data1? We can look at another piece of code, online code. Modify the bus to

data () {
 return {
  // One more layer structure  val: {
   result: 0
  }
 }
},
created () {
 this.$on('update1', val => {
  ('Trigger 1', i1++)
   = val
 })
}

The data receiving component is changed to

// template
dataGet the direct modification value：{{dataResult}}
dataGet the direct modification value的父层：{{dataVal}}
computedDependency directly modify value：{{computedResult}}
// js
data () {
  return {
   // Get the direct modification value   dataResult: ,
   // Get the parent layer that directly modify the value   dataVal: 
  }
 },
 computed: {
  computedResult () {
   // Depend on directly modifying the value   return 
  }
 }

It can be seen that data that directly modify the value cannot be dynamically responded.

Why use events

Actually, it doesn't need to$emitTrigger, use = 1Direct assignment is also possible, so why not do this?

Simplified version of vuex

In fact, this eventBus is a simplified version of vuex. There is a passage in the vue document:

The component does not allow the state belonging to the store instance to be directly modified, but should execute action to distribute (dispatch) event notification store to change, and we finally reached the Flux architecture. The advantage of this agreement is that we can record all state changes that occur in the store.

The store corresponds to the bus instance, the state corresponds to data, the action corresponds to events, and the dispatch corresponds to $emit. At the same time, the way components in vuex obtain data is through computing attributes. In fact, the understanding and use of vuex and Flux architectures is not that difficult, right?

Summarize

The above is the vue data transmission introduced by the editor to you - I have special implementation skills, I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. Thank you very much for your support for my website!