在最近的构建的一个网络推送 服务的项目中， 我想让我的ui响应应用程序级别的事件 (语义上，如果你会的话) 因为有几个组件需要从系统中获取信息，但不相互依赖，我希望他们能够独立管理自己的“业务逻辑”.
我环顾四周,很多不同的工具来帮助我, 但是因为我经常有很严重的NIH综合症和我认为人们可以很快实现自己的基础元素, 我决定迅速把它绑定到一个简单的客户端PubSub服务 — 它工作得很好，满足了我的需求.
我在考虑是否应该使用一个自定义的DOM事件和利用现有的DOM已经提供给开发者的基础设施，通过使用 addEventListener函数，能够具有发布事件和消费事件的能力 — 唯一的问题是，你必须把事件绑定到一个DOM元素或者window，因为你没有一个继承或混合了EventTarget的模型。
思考: 有目标为对象，将有助于避免创建自定义的发布订阅系统的需要.
有了这个约束, 一段代码已经出现,不管是否错误至少是我自己写的,我草拟了一个粗略的计划:
立即学习“Java免费学习笔记（深入）”；
/* When a user is added, do something useful (like update UI) */EventManager.subscribe('useradded', function(user) {
console.log(user)
});/* The UI submits the data, lets publish the event. */form.onsubmit(function(e) {
e.preventDefault(); // do something with user fields
EventManager.publish('useradded', user);
})所有这一切并不新鲜. Redux 和许多其他的系统大多数情况下已经是这样做的了, 它们负责帮你管理应用状态.在我的脑海中,我确定不需要一个状态模型来管理状态而且和浏览器中的状态区别开来。
这是一个非常简单的实现，但是抽象非常重要。至少对我来说是这样的。
var EventManager = new (function() {
var events = {};
this.publish = function(name, data) {
return new Promise(function(resolve, reject) {
var handlers = events[name];
if(!!handlers === false) return;
handlers.forEach(function(handler) {
handler.call(this, data);
});
resolve();
});
};
this.subscribe = function(name, handler) {
var handlers = events[name];
if(!!handlers === false) {
handlers = events[name] = [];
}
handlers.push(handler);
};
this.unsubscribe = function(name, handler) {
var handlers = events[name];
if(!!handlers === false) return;
var handlerIdx = handlers.indexOf(handler);
handlers.splice(handlerIdx);
};
});我的简单的发布订阅（PubSub）系统可能充满了bug, 但是我喜欢它。
