An in-depth explanation of the observer pattern in Javascript (graphic tutorial)

The observer pattern, also known as the publish-subscribe pattern, is one of the most commonly used design patterns. The following article mainly gives you an in-depth introduction to the relevant materials of the observer pattern in Javascript.

Introduction

The observer pattern is also called publish/subscribe pattern (Publish/Subscribe). It defines a one-to-many relationship, allowing multiple observer objects to At the same time, a certain topic object is monitored. When the status of this topic object changes, all observer objects will be notified, so that they can automatically update themselves. To be honest, if we were not writing slightly low-level code, we might not use it. But having it will make the code more flexible and regular, reduce redundant code, and facilitate the development of modules and functions.

Benefits of using the observer pattern:

1. Supports simple broadcast communication and automatically notifies all subscribed objects.

2. After the page is loaded, the target object can easily have a dynamic relationship with the observer, which increases flexibility.

3. The abstract coupling relationship between the target object and the observer can be independently extended and reused.

Introduction

In front-end business, the place that may be used more may be custom events.
In fact, the events of the browser are also observer mode

p.onclick = function click() {
 console.log('click')
}

Here function click subscribes to the click event of p. When our mouse clicks, the event is published , the corresponding function will be executed. This function click is an observer.

Concrete understanding

In fact, you can understand it simply by looking at the code implementation. But everything is connected. The design of these programming models also comes from life experience. Therefore, concrete understanding is also a very important experience.

Let’s take an example of a wedding banquet. For example, a good friend of yours is getting married. "Getting married" doesn't happen every day, it only happens once or twice in a lifetime (maybe more). So our "going to his wedding" definitely doesn't happen every day, but only on certain occasions. when. I definitely can't ask him every day, 'Are you getting married today? I'll come to the banquet.' Once or twice is okay, ask every day, sb. If you are a single guy who can't find a partner, and you ask this question every day, he won't kill you. .

Then there needs to be an event released here, which is to 'notify you'.

As an observer, I subscribed to the event of his 'marriage'. We are good friends and I will definitely go to his wedding. We have already agreed. Then I am the observer, and 'I go to the wedding' is the corresponding action. When I subscribe to the 'marriage' event, I don't need to ask him every day, what should I do, pick up girls, make dinner dates, watch movies, date... whatever.

When he posted the event of 'marriage', the notification was sent to me, and I went to do the 'attend the wedding banquet' function at a specific time...

//模拟代码
//我订阅了'marry' 事件
wo.on('marry',function(){
 //去参加婚礼酒席
})
//然后他发布。比如浏览器的点击
// 对应的我的 function就会执行

Decoupling/Module/Function

In fact, in the code, an intermediary similar to an intermediate service is needed to manage publishing and subscription.

For example, the event handler in the browser provides a subscription interface, and then receives the 'event' signal and publishes it to you. Let the js code have contact and interaction with the browser. But originally they were two different things.

In my opinion, the biggest benefit of the observer pattern is decoupling, which will allow us to separate the code into functions and modules, making it clearer, lower development costs, and easier to maintain.

For example:

1. For the view display layer and model (data processing) logic layer in our project, we first write the page, ajax, string splicing, and request an interface. Fight it and give it to dom. Maybe we have a js file and a function that requests an interface and is responsible for the display of the view.

var xhr = new XMLHttpRequest ()
 xhr.open('get',url)
 xhr.onreadystatechange = function () {
 if(this.readyState !== 4) return
 if(this.status === 200) {
 ps.innerHTML = &#39;<p>&#39; + this.response + &#39;</p>&#39;
 //
 }
 }
 xhr.responseType = &#39;json&#39;
 xhr.send(null)

In fact, the request should be separated from the display rendering.

//请求
function getData () {
 var xhr = new XMLHttpRequest ()
 xhr.open('get',url)
 xhr.onreadystatechange = function () {
 if(this.readyState !== 4) return
 if(this.status === 200) {
 this.emit('渲染')
 // 发布
 }
 }
 xhr.responseType = 'json'
 xhr.send(null)
}
//渲染
function view () {}
xhr.on('渲染',view)

It can also be done by placing a callback directly on the status code 200. But if I have two render functions that handle different things, do I have to change them to different functions each time? Do I have to write the same request process again?

In the words of an observer

function view1 () {}
function view2 () {}
function view3 () {}
function view4 () {}
if(我要渲染view1) {
 xhr.on('渲染',view1) //订阅
 xhr.on('渲染',view2)
}else{
 xhr.on('渲染',view3)
 xhr.on('渲染',view4)
}

The advantage lies in my getData function. The method is only responsible for requesting data, and then he An interface will be exposed for me to add methods. In this way, my getData is a relatively complete functional module. No matter how many situations I encounter, the code in my getData will not change.

Sometimes we often change the code we wrote before in order to implement business and add a new function, causing our original functional modules to be changed beyond recognition.

And there will be a lot of duplicate code.

process? or module?

Of course it is very difficult to seal a good and complete functional module, but we must at least have a start.

Subscribe to add methods, and execute them when the event pool is published.

2. MV* class framework

MVC也是一种设计模式，这里面也都应用了观察者。

他内部也都是各种发布订阅，好像是一个观察者模型，从而实现了一个模拟的内存中的dom改变，计算出那个DOM节点应该改变。当然具体实现要做好多事情…就不…

3、redux

简单实现一个createstore函数

//这是一个工厂函数，可以创建store
const createStore = (reducer) => {
 let state; // 定义存储的state
 let listeners = [];
 // getState的作用很简单就是返回当前是state
 const getState = ()=> state;
 //定义一个派发函数
 //当在外界调用此函数的时候，会修改状态
 const dispatch = (action)=>{
 //调用reducer函数修改状态，返回一新的状态并赋值给这个局部状态变量
 state = reducer(state,action);
 //依次调用监听函数，通知所有的监听函数
 listeners.forEach(listener => listener());
 }
 //订阅此状态的函数，当状态发生变化的时候记得调用此监听函数
 const subscribe = function(listener){
 //先把此监听 加到数组中
 listeners.push(listener);
 //返回一个函数，当调用它的时候将此监听函数从监听数组移除
 return function(){
  listeners = listeners.filter(l => l != listener);
 }
 }
 //默认调用一次dispatch给state赋一个初始值
 dispatch();
 return {
 getState,
 dispatch,
 subscribe
 }
}
let store = createStore(reducer);
//把数据渲染到界面上
const render = () => {
 document.body.innerText = store.getState();
}
// 订阅状态变化事件，当状态变化时用监听函数
store.subscribe(render);
render();
var INCREASE_ACTION = {type: 'INCREMENT'};
document.addEventListener('click', function (e) {
 //触发一个Action
 store.dispatch(INCREASE_ACTION);
})

4、在node 中的作用 大多数时候我们不会直接使用 EventEmitter，而是在对象中继承它。包括fs、net、 http 在内的，只要是支持事件响应的核心模块都是 EventEmitter 的子类。

实现一个可以发布订阅的类

'use strict'
class EmitterEvent {
 constructor() {
 //构造器。实例上创建一个事件池
 this._event = {}
 }
 //on 订阅
 on (eventName, handler) {
 // 根据eventName，事件池有对应的事件数组，
 就push添加，没有就新建一个。
 // 严谨一点应该判断handler的类型，是不是function
 if(this._event[eventName]) {
 this._event[eventName].push(handler)
 } else {
 this._event[eventName] = [handler]
 }
 }
 emit (eventName) {
 // 根据eventName找到对应数组
 var events = this._event[eventName];
 // 取一下传进来的参数，方便给执行的函数
 var otherArgs = Array.prototype.slice.call(arguments,1)
 var that = this
 if(events) {
 events.forEach((event) => {
 event.apply(that, otherArgs)
 })
 }
 }
 // 解除订阅
 off (eventName, handler) {
 var events = this._event[eventName]
 if(events) {
 this._event[eventName] = events.filter((event) => {
 return event !== handler
 })
 }
 }
 // 订阅以后，emit 发布执行一次后自动解除订阅
 once (eventName, handler) {
 var that = this
 function func () {
 var args = Array.prototype.slice.call(arguments,0)
 handler.apply(that, args)
 this.off(eventName,func)
 }
 this.on(eventName, func)
 }
}
var event = new EmitterEvent()
function a (something) {
 console.log(something,'aa-aa')
}
function b (something) {
 console.log(something)
}
 event.once('dosomething',a)
 event.emit('dosomething', 'chifan')
 //event.emit('dosomething')
// event.on('dosomething',a)
// event.on('dosomething',b)
// event.emit('dosomething','chifan')
// event.off('dosomething',a)
// setTimeout(() => {
// event.emit('dosomething','hejiu')
// },2000)

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

JS DOM元素常见增删改查操作详解

JS刷新页面方法总结

JS callback回调函数使用案例详解

The above is the detailed content of An in-depth explanation of the observer pattern in Javascript (graphic tutorial). For more information, please follow other related articles on the PHP Chinese website!