Detailed explanation of the observer mode starting from the component value transfer of Vue

Observer Pattern

First of all, mentioning the observer pattern reminds me of MVVM. The MVVM architecture pattern seems to use the idea of ​​observers.

Let's follow the convention and understand what the observer mode is.

The observer pattern is similar to the publish-subscribe pattern. To complete this action, there must be at least two different objects, or multiple objects. It is more like a one-to-many dependency relationship, that is, when the state of one object changes, the states of all related objects will change. For example, in the Moments feature, a person may have hundreds of friends. When I post a Moments post, all my friends will see it. When another person likes it, all your friends who like it will also receive a notification. This is very much like an observer, that is, I am the publisher and my friends are subscribers.

Vue pass value

Then let's take a look at what Vue is. Everyone knows the principle of Vue. It is a bottom-up, deeply responsive, two-way binding mode, namely MVVM. In other words, Vue pays attention to changes in the model. Changes in the model allow the MVVM framework to update the DOM, thereby generating view changes.

Here is a common example in a project:

In writing Vue projects, we have used parent-child component value transfer, but how to implement brother component value transfer? First, we can use Vuex, which is very common, but there is another method that I don’t know if you have used, which is Bus. This Bus is just a name. It doesn’t matter what you call it. You can call it an airplane or a cannon. It doesn’t matter. Let’s mainly look at how it is implemented:

The first step is to register the bus in main.js

Vue.prototype.$Bus = new Vue()

We registered a global variable $Bus in the prototype of vue, and its value is the instance of vue. That is to say, up to now, $Bus has all the properties and methods of vue, which is easy to operate now.

In the second step, we start sending messages

This is in line with the publish-subscribe model of the observer pattern.

We write the following code in component 1:

<template>
    <div>
        <button @click="send">Send</button>
    </div>
</template>

<script>
export default {
    methods: {
        send () {
            this.$Bus.$emit("send",'Received information')
        }
    }
}
</script>

Click the button to send a message. This button acts as a publisher. We use the $emit API of vue, so what is a subscriber? Even if I didn't tell you, you should have guessed it. Yes, it's him.

Step 3: Receive messages in component 3

<template>
    <div>
        {{message}}
    </div>
</template>

<script>
export default {
    data () {
        return {
            message: ''
        }
    },
    mounted () {
        this.$Bus.$on('send', (msg) => {
            this.message = msg
        })
    }
}
</script>

Use the $on attribute as the receiver

As can be seen from the above, Vue uses the idea of ​​observers in many places, including its two-way binding.

The mechanism of Vue

From the above picture, we can see that vue hijacks the data through Object.defineProperty, then makes a transfer in the middle, and finally renders it to the vue layer.

What we can be sure of is that vue.js borrowed from the observer pattern, but I feel there is still a little difference. The observer pattern focuses on event-driven. For example, when I buy a house, there may not be any suitable houses when I first consult with the salesperson. Then the salesperson will say to you: "If there is a suitable house, we will notify you as soon as possible." When there is a new house, he will call you to inform you. The root of this series is the event of buying a house, which drives the entire process. As we all know, Vue is data-driven, that is, only if the value in the data changes, Object.defineProperty will hijack it to update the DOM and trigger the update of the view.

So is there anything that is more in line with the characteristics of the observer pattern?

Of course it is the node.js events.

First, let's look at the workflow of events:

var events = require('events');
//Create eventEmitter object var eventEmitter = new events.EventEmitter();
// Create event handler var connectHandler = function connected() {
   console.log('Connection successful.');
   // Trigger data_received event eventEmitter.emit('data_received');
}
// Bind connection event handler eventEmitter.on('connection', connectHandler);
// Use anonymous function to bind data_received event eventEmitter.on('data_received', function(){
   console.log('Data received successfully.');
});
//Trigger connection event eventEmitter.emit('connection');
console.log("Program execution completed.");

Output:

This is completely in line with the working mode of the observer, published by emit and received by on. Therefore, node.js provides a good monitoring mechanism and handles the entire transaction. It supports the most distinctive I/O mode of nodejs. For example, when we start the http service, we will listen to its connect/close, and when we use http.request, we will listen to data/end, etc.

Are there any similar cases?

Of course, js has an event listener ---- addEventListener, which also has the meaning of an observer. I won’t go into details about its usage, I believe everyone is familiar with it.

In fact, as long as you think about it carefully, there are still many places where there are observers. The simplest one is a click event. Doesn’t it also have its meaning? The publisher is a button, and the receiver can be a form, a pop-up layer, or anything else.

The significance of the observer mode

First, let's talk about its advantages:

1. The observer pattern requires a coupling between the observer and the observed. It requires a more abstract way to connect the two.

2. The observer mode supports broadcasting, which is a one-to-many relationship. This makes it easy for us to think of a technology, which is socket. For details, please refer to the vue project using websocket technology

However, he also has advantages and disadvantages:

1. Creating a subscriber consumes a certain amount of time and memory.

2. When subscribing to a message, perhaps the message has not occurred, but the subscriber will always exist in memory.

3. The observer pattern weakens the connection between objects, which is a good thing. However, if it is overused, the connection between objects will be hidden very deeply, making the project difficult to track, maintain and understand.

Wait, there is another model called publish-subscribe model. Many people think it is the observer model (including me). Later, I checked it on the Internet and found that they are still different. We can say that the observer model is very similar to the publish-subscribe model, really similar, but there are still some differences in essence. The most fundamental difference is the scheduling center.

For example, the observer pattern focuses more on the target and observer being abstract classes. For example, in the weather forecast, observer A is responsible for monitoring weather changes, and if B wants to know about weather changes, it needs to register itself with A. When the weather changes, A triggers the weather change and schedules B's interface to update the changes.

How does the publish-subscribe model accomplish this? If A wants to sense weather changes, it needs B, the dispatch center, and B needs to rely on C's trigger to get the weather changes. Maybe I didn't explain it very clearly. There are two better pictures on the Internet.

The above is a detailed explanation of the observer mode starting from the value passing of Vue components. For more information about the observer mode starting from the value passing of Vue components, please pay attention to other related articles on 123WORDPRESS.COM!