我喜欢的三项工作内容：前端开发，需求分析和项目管理。
摘要: 之前的项目一直采用grunt来构建，然后用requirejs做模块化，requirejs官方有提供grunt的插件来做压缩合并。现在的项目切到了gulp，模块化用起了seajs，自然而然地也想到了模块合并压缩的问题。然后一开始在解决这个问题的时候，并不是很顺利，在npm上并没有那种特别流行的专门用来做seajs合并压缩的gulp插件，虽然在seajs的github上也看了不少的issue，但是大多...
09:24 流云诸葛 阅读(269) 评论(7)
摘要: 自从开始做前端开发以来，我发现在开发页面的时候，总是有一个问题十分影响自己的开发效率，这个问题就是css的命名，主要是指css类选择器的命名。这个问题主要体现在：第一，有的内容你压根想不出用什么名字来给它命名，因为一般命名总是考虑语义化，好让其他人看到这个css类的名字就知道它是作用于哪一个内容的，但是由于网页内容的复杂性和多样性，你很难保证每个部分都能起一个合适的名字，即使你最终迫不得已想出了一...
08:42 流云诸葛 阅读(913) 评论(19)
摘要: 这是上周工作中写到的一个功能，大概的效果就是页面中有几处数字，统计公司的一些业务信息，需要在第一次出现的时候，做一个从0开始增长，大概2秒自动增长到真实数值，并停止增长的效果。这个问题的重点在于解决如何保证不同大小的数字都在2秒左右的时间自动增长完成，以及还有考虑延迟初始化的处理。后面这一点是为了保证，只有当数字第一次进入浏览器可视区域的时候，才会看到效果，因为这些数字有可能不在首屏的内容内，必须...
08:39 流云诸葛 阅读(606) 评论(9)
摘要: 上文《简洁易用的表单数据设置和收集管理组件》介绍了我自己的表单管理的核心内容，本文在上文的基础上继续介绍自己关于表单初始值获取和设置以及表单数据提交等内容方面的做法，上文的组件粒度很小，都是跟单个表单元素相关的某种特定类型的组件，所以内容很多；本文要介绍的内容集中于整个表单组件本身，有点像上文介绍的formMap.js组件，但不同的是在我自己的项目中form.js用的更多，formMap几乎不用，...
10:35 流云诸葛 阅读(821) 评论(3)
摘要: 这篇文章要分享的是我在做表单界面开发的一部分经验，关于表单数据设置和收集这一块的。整体而言，这篇文章总结的东西有以下的特点： 1）api简单，使用起来很容易； 2）简化了表单新增和编辑，可以让新增和编辑使用同一个表单页面； 3）基本上与UI分离，所以很容易应用到各类项目的开发当中。 涉及到的组件不止一个，而且将来还会扩充，这些组件都是根据以前的工作经验开发出来的，没有...
10:25 流云诸葛 阅读(603) 评论(7)
摘要: 本文介绍自己最近做省市级联的类似的级联功能的实现思路，为了尽可能地做到职责分离跟表现与行为分离，这个功能拆分成了2个组件并用到了单链表来实现关键的级联逻辑，下一段有演示效果的gif图。虽然这是个很常见的功能，但是本文的实现逻辑清晰，代码好理解，脱离了省市级联这样的语义，考虑了表现与行为的分离，所以希望本文的内容能够为你的工作带来一些参考的价值，欢迎阅读和指正。
07:49 流云诸葛 阅读(364) 评论(6)
摘要: 虽然jquery的较新的api已经很好用了， 但是在实际工作还是有做二次封装的必要，好处有：1，二次封装后的API更加简洁，更符合个人的使用习惯；2，可以对ajax操作做一些统一处理，比如追加随机数或其它参数。同时在工作中，我们还会发现，有一些ajax请求的数据，对实时性要求不高，即使我们把第一次请求到的这些数据缓存起来，然后当相同请求再次发起时直接拿之前缓存的数据返回也不会对相关功能有影响，通过这种手工的缓存控制，多多少少也能帮助我们提高网页的性能。本文介绍我自己关于这两方面问题的做法，欢迎交流和指正。
07:43 流云诸葛 阅读(791) 评论(3)
摘要: 本文要介绍的是网页中常见的图片上传后直接在页面生成小图预览的实现思路，考虑到该功能有一定的适用性，于是把相关的逻辑封装成了一个ImageUploadView组件，实际使用效果可查看下一段的git效果图。在实现这个组件的过程中，有用到前面几篇博客介绍的相关内容，比如继承库class.js，任意组件的事件管理库eventBase.js，同时包含进了自己对职责分离，表现与行为分离这两方面的思考，欢迎阅读与交流。
09:50 流云诸葛 阅读(692) 评论(2)
摘要: 本文介绍一个jquery的小技巧，能让任意组件对象都能支持类似DOM的事件管理，也就是说除了派发事件，添加或删除事件监听器，还能支持事件冒泡，阻止事件默认行为等等。在jquery的帮助下，使用这个方法来管理普通对象的事件就跟管理DOM对象的事件一模一样，虽然在最后当你看到这个小技巧的具体内容时，你可能会觉得原来如此或者不过如此，但是我觉得如果能把普通的发布-订阅模式的实现改成DOM类似的事件机制，那开发出来的组件一定会有更大的灵活性和扩展性，而且我也是第一次使用这种方法（见识太浅的原因），觉得它的使用价值还蛮大的，所以就把它分享出来了。
09:22 流云诸葛 阅读(707) 评论(2)
摘要: jquery现在的事件API：on，off，trigger支持带命名空间的事件，当事件有了命名空间，就可以有效地管理同一事件的不同监听器，在定义组件的时候，能够避免同一元素应用到不同组件时，同一事件类型之间的影响，还能控制一些意外的事件冒泡。在实际工作中，相信大家都用的很多，但是不一定了解它的所有细节，至少我有这样的经验，经常在碰到疑惑的时候，还得重新写例子去验证它的相关作用，所以本文想把事件命名空间相关的细节都梳理出来，将来再犯迷糊的时候可以回来翻着看看以便加深对它的理解和运用。
09:28 流云诸葛 阅读(702) 评论(8)
摘要: 最近的工作在做一个多步骤多分步的表单页面，这个多步骤多分步的意思是说这个页面的业务是分多个步骤完成的，每个步骤可能又分多个小步骤来处理，大步骤之间，以及小步骤之间都是一种顺序发生的业务关系。我把这个功能相关的一些逻辑抽象成了一个组件StepJump，这个组件能够实现纯静态的分步切换和跳转，以及跟业务相结合的复杂逻辑，有一定的通用性和灵活性，本文主要介绍它的功能要求和实现思路。
08:58 流云诸葛 阅读(444) 评论(0)
摘要: 本文是对《详解Javascript的继承实现》的补充，针对上文继承库实现的注意事项和阅读《JavaScript面向对象编程指南》一书关于继承部分的内容进行说明。
15:41 流云诸葛 阅读(351) 评论(2)
摘要: 希望本文可以帮助你写出更流弊的javascript：）
08:36 流云诸葛 阅读(986) 评论(4)
摘要: 上文提供了一个改进版的sticky组件，并将演示效果应用到了自己的博客。有了类似sticky的这种简单组件，我们就可以在利用它开发更丰富的效果，比如本文要介绍的tab导航和滚动导航。实现简单，演示效果如下
09:14 流云诸葛 阅读(386) 评论(0)
摘要: 上上篇博客介绍了一个sticky组件的简洁实现，经过这两天的思考，发现上次提供的实现还有较多不足的地方，另外跟别的网站上实现的效果在取消固定的时候也有一些不同，上次提供的取消固定的处理方式不好，本文在上文的基础上，提供一个改进版的sticky组件，功能更加完善，希望您有兴趣阅读。代码演示见本博客滚动时侧边栏的效果。
08:48 流云诸葛 阅读(280) 评论(3)
摘要: 这段时间状态比较清闲，我想是时候以一个前端开发人员的态度来整理下自己的博客设置了，除了UI上的一些调整，考虑最多的就是怎么优化我的这些个性化内容，让博客的访问速度的更快
14:42 流云诸葛 阅读(602) 评论(1)
摘要: sticky组件，通常应用于导航条或者工具栏，当网页在某一区域滚动的时候，将导航条或工具栏这类元素固定在页面顶部或底部，方便用户快速进行这类元素提供的操作。本文介绍这种组件的实现思路，并提供一个同时支持将sticky元素固定在顶部或底部的具体实现，由于这种组件在网站中非常常见，所以有必要掌握它的实现方式，以便在有需要的时候基于它的思路写出功能更多的组件出来。
08:59 流云诸葛 阅读(297) 评论(0)
摘要: 本文内容相当简单，所以没有发布到博客园首页，如果你不幸看到，那只能是我这篇文章的荣幸，谢谢你的大驾光临~
23:12 流云诸葛 阅读(292) 评论(7)
摘要: 在做h5移动页面，相信大家一定碰到过页面已经打开，但是里面的图片还未加载出来的情况，这种问题虽然不影响页面的功能，但是对于不利于用户体验。抛开网速的原因，解决这个问题有多方面的思路：最基本的，要从http请求合并，缓存管理，图片压缩等方面做性能优化；另外就是可以对页面里用到的所有图片做预加载的处理。
08:51 流云诸葛 阅读(1832) 评论(8)
摘要: 简单说，有限状态机是一种模型，用来模拟现实世界的事物，但是很多js组件也都可以用有限状态机来描述，只要这个组件的行为可以通过几个有限的状态来划分，利用状态机写出来的代码，逻辑思维或者说面向对象思维更加清晰，表达能力更强。
09:16 流云诸葛 阅读(744) 评论(0)诸葛流云是什么时候变厉害的？_百度知道
诸葛流云是什么时候变厉害的？
感觉他一直也没有多厉害，但后来对抗七夜时怎么又变得很强了？
提问者采纳
而且又有燕赤侠当他师父他是天生的厉害，有基因关系，他妈后来不是一条龙吗
提问者评价
为什么之前没表现出来呢？
其他类似问题
为您推荐：
诸葛流云的相关知识
其他1条回答
问题他本人啊#24
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁我喜欢的三项工作内容：前端开发，需求分析和项目管理。
本文介绍一个jquery的小技巧，能让任意组件对象都能支持类似DOM的事件管理，也就是说除了派发事件，添加或删除事件监听器，还能支持事件冒泡，阻止事件默认行为等等。在jquery的帮助下，使用这个方法来管理普通对象的事件就跟管理DOM对象的事件一模一样，虽然在最后当你看到这个小技巧的具体内容时，你可能会觉得原来如此或者不过如此，但是我觉得如果能把普通的发布-订阅模式的实现改成DOM类似的事件机制，那开发出来的组件一定会有更大的灵活性和扩展性，而且我也是第一次使用这种方法（见识太浅的原因），觉得它的使用价值还蛮大的，所以就把它分享出来了。
在正式介绍这个技巧之前，得先说一下我之前考虑的一种方法，也就是发布-订阅模式，看看它能解决什么问题以及它存在的问题。
1. 发布-订阅模式
很多博客包括书本上都说javascript要实现组件的自定义事件的话，可以采用发布-订阅模式，起初我也是坚定不移地这么认为的，于是用jquery的写了一个：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('./class');
function isFunc(f) {
return Object.prototype.toString.apply(f) === '[object Function]';
* 这个基类可以让普通的类具备事件驱动的能力
* 提供类似jq的on off trigger方法，不考虑one方法，也不考虑命名空间
* var e = new EventBase();
* e.on('load', function(){
console.log('loaded');
* e.trigger('load');//loaded
* e.off('load');
var EventBase = Class({
instanceMembers: {
init: function () {
this.events = {};
//把$.Callbacks的flag设置成一个实例属性，以便子类可以覆盖
this.CALLBACKS_FLAG = 'unique';
on: function (type, callback) {
type = $.trim(type);
//如果type或者callback参数无效则不处理
if (!(type && isFunc(callback))) return;
var event = this.events[type];
if (!event) {
//定义一个新的jq队列，且该队列不能添加重复的回调
event = this.events[type] = $.Callbacks(this.CALLBACKS_FLAG);
//把callback添加到这个队列中，这个队列可以通过type来访问
event.add(callback);
off: function (type, callback) {
type = $.trim(type);
if (!type) return;
var event = this.events[type];
if (!event) return;
if (isFunc(callback)) {
//如果同时传递type跟callback，则将callback从type对应的队列中移除
event.remove(callback);
//否则就移除整个type对应的队列
delete this.events[type];
trigger: function () {
var args = [].slice.apply(arguments),
type = args[0];//第一个参数转为type
type = $.trim(type);
if (!type) return;
var event = this.events[type];
if (!event) return;
//用剩下的参数来触发type对应的回调
//同时把回调的上下文设置成当前实例
event.fireWith(this, args.slice(1));
return EventB
（基于seajs以及《》介绍的继承库class.js）
只要任何组件继承这个EventBase，就能继承它提供的on off trigger方法来完成消息的订阅，发布和取消订阅功能，比如我下面想要实现的这个FileUploadBaseView：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('./class');
var EventBase = require('./eventBase');
var DEFAULTS = {
data: [], //要展示的数据列表，列表元素必须是object类型的，如[{url: 'xxx.png'},{url: 'yyyy.png'}]
sizeLimit: 0, //用来限制BaseView中的展示的元素个数，为0表示不限制
readonly: false, //用来控制BaseView中的元素是否允许增加和删除
onBeforeRender: $.noop, //对应beforeRender事件，在render方法调用前触发
onRender: $.noop, //对应render事件，在render方法调用后触发
onBeforeAppend: $.noop, //对应beforeAppend事件，在append方法调用前触发
onAppend: $.noop, //对应append事件，在append方法调用后触发
onBeforeRemove: $.noop, //对应beforeRemove事件，在remove方法调用前触发
onRemove: $.noop //对应remove事件，在remove方法调用后触发
* 数据解析，给每个元素的添加一个唯一标识_uuid，方便查找
function resolveData(ctx, data){
var time = new Date().getTime();
return $.map(data, function(d){
d._uuid = '_uuid' + time + Math.floor(Math.random() * 100000);
var FileUploadBaseView = Class({
instanceMembers: {
init: function (options) {
this.base();
this.options = this.getOptions(options);
getOptions: function(options) {
return $.extend({}, DEFAULTS, options);
render: function(){
append: function(data){
remove: function(prop){
extend: EventBase
return FileUploadBaseV
实际调用测试如下：
测试中，实例化了一个FileUploadBaseView对象f，并设置了它的name属性，通过on方法添加一个跟hello相关的监听器，最后通过trigger方法触发了hello的监听器，并传递了额外的两个参数，在监听器内部除了可以通过监听器的函数参数访问到trigger传递过来的数据，还能通过this访问f对象。
从目前的结果来说，这个方式看起来还不错，但是在我想要继续实现FileUploadBaseView的时候碰到了问题。你看我在设计这个组件的时候那几个订阅相关的option：
  我原本的设计是：这些订阅都是成对定义，一对订阅跟某个实例方法对应，比如带before的那个订阅会在相应的实例方法（render）调用前触发，不带before的那个订阅会在相应的实例方法（render）调用后触发，而且还要求带before的那个订阅如果返回false，就不执行相应的实例方法以及后面的订阅。最后这个设计要求是考虑到在调用组件的实例方法之前，有可能因为一些特殊的原因，必须得取消当前实例方法的调用，比如调用remove方法时有的数据不能remove，那么就可以在before订阅里面做一些校验，能删除的返回true，不能删除的返回false，然后在实例方法中触发before的订阅后加一个判断就可以了，类似下面的这种做法：
但是这个做法只能在单纯的回调函数模式里实现，在发布-订阅模式下是行不通的，因为回调函数只会跟一个函数引用相关，而发布-订阅模式里，同一个消息可能有多个订阅，如果把这种做法应用到发布-订阅里面，当调用this.trigger('beforeRender')的时候，会把跟beforeRender关联的所有订阅全部调用一次，那么以哪个订阅的返回值为准呢？也许你会说可以用队列中的最后一个订阅的返回值为准，在大多数情况下也许这么干没问题，但是当我们把“以队列最后的一个订阅返回值作为判断标准”这个逻辑加入到EventBase中的时候，会出现一个很大的风险，就是外部在使用的时候，一定得清楚地管理好订阅的顺序，一定要把那个跟校验等一些特殊逻辑相关的订阅放在最后面才行，而这种跟语法、编译没有关系，对编码顺序有要求的开发方式会给软件带来比较大的安全隐患，谁能保证任何时候任何场景都能控制好订阅的顺序呢，更何况公司里面可能还有些后来的新人，压根不知道你写的东西还有这样的限制。
解决这个问题的完美方式，就是像DOM对象的事件那样，在消息发布的时候，不是简简单单的发布一个消息字符串，而是把这个消息封装成一个对象，这个对象会传递给它所有的订阅，哪个订阅里觉得应该阻止这个消息发布之后的逻辑，只要调用这个消息的preventDefault()方法，然后在外部发布完消息后，调用消息的isDefaultPrevented()方法判断一下即可：
而这个做法跟使用jquery管理DOM对象的事件是一样的思路，比如bootstrap的大部分组件以及我在前面一些博客中写的组件都是用的这个方法来增加额外的判断逻辑，比如bootstrap的alert组件在close方法执行的时候有一段这样的判断：
按照这个思路去改造EventBase是一个解决问题的方法，但是jquery的一个小技巧，能够让我们把整个普通对象的事件管理变得更加简单，下面就让我们来瞧一瞧它的庐山真面目。
2. jquery小技巧模式
如果在定义组件的时候，这个组件是跟DOM对象有关联的，比如下面这种形式：
那么我们可以完全给这个组件添加on off trigger one这几个常用事件管理的方法，然后将这些方法代理到$element的相应方法上： 
通过代理，当调用组件的on方法时，其实调用的是$element的on方法，这样的话这种类型的组件就能支持完美的事件管理了。
第一个技巧只能适用于跟DOM有关联的组件，对于那些跟DOM完全没有关联的组件该怎么添加像前面这样完美的事件管理机制呢？其实方法也很简单，只是我自己以前真的是没这么用过，所以这一次用起来才会觉得特别新鲜： 
看截图中框起来的部分，只要给jquery的构造函数传递一个空对象，它就会返回一个完美支持事件管理的jquery对象。而且除了事件管理的功能外，由于它是一个jquery对象。所以jquery原型上的所有方法它都能调用，将来要是需要借用jquery其它的跟DOM无关的方法，说不定也能参考这个小技巧来实现。
3. 完美的事件管理实现
考虑到第2部分介绍的2种方式里面有重复的逻辑代码，如果把它们结合起来的话，就可以适用所有的开发组件的场景，也就能达到本文标题和开篇提到的让任意对象支持事件管理功能的目标了，所以最后结合前面两个技巧，把EventBase改造如下（是不是够简单）：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('./class');
* 这个基类可以让普通的类具备jquery对象的事件管理能力
var EventBase = Class({
instanceMembers: {
init: function (_jqObject) {
this._jqObject = _jqObject && _jqObject instanceof $ && _jqObject || $({});
on: function(){
return $.fn.on.apply(this._jqObject, arguments);
one: function(){
return $.fn.one.apply(this._jqObject, arguments);
off: function(){
return $.fn.off.apply(this._jqObject, arguments);
trigger: function(){
return $.fn.trigger.apply(this._jqObject, arguments);
return EventB
实际调用测试如下
1）模拟跟DOM关联的组件
测试代码一：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('mod/class');
var EventBase = require('mod/eventBase');
var Demo = window.demo = Class({
instanceMembers: {
init: function (element,options) {
this.$element = $(element);
this.base(this.$element);
//添加监听
this.on('beforeRender', $.proxy(options.onBeforeRender, this));
this.on('render', $.proxy(options.onRender, this));
render: function () {
//触发beforeRender事件
var e = $.Event('beforeRender');
this.trigger(e);
if(e.isDefaultPrevented())return;
//主要逻辑代码
console.log('render complete!');
//触发render事件
this.trigger('render');
extend: EventBase
var demo = new Demo('#demo', {
onBeforeRender: function(e) {
console.log('beforeRender event triggered!');
onRender: function(e) {
console.log('render event triggered!');
demo.render();
在这个测试里， 我定义了一个跟DOM关联的Demo组件并继承了EventBase这个事件管理的类，给beforeRender事件和render事件都添加了一个监听，render方法中也有打印信息来模拟真实的逻辑，实例化Demo的时候用到了#demo这个DOM元素，最后的测试结果是：
完全与预期一致。
测试代码二：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('mod/class');
var EventBase = require('mod/eventBase');
var Demo = window.demo = Class({
instanceMembers: {
init: function (element,options) {
this.$element = $(element);
this.base(this.$element);
//添加监听
this.on('beforeRender', $.proxy(options.onBeforeRender, this));
this.on('render', $.proxy(options.onRender, this));
render: function () {
//触发beforeRender事件
var e = $.Event('beforeRender');
this.trigger(e);
if(e.isDefaultPrevented())return;
//主要逻辑代码
console.log('render complete!');
//触发render事件
this.trigger('render');
extend: EventBase
var demo = new Demo('#demo', {
onBeforeRender: function(e) {
console.log('beforeRender event triggered!');
onRender: function(e) {
console.log('render event triggered!');
demo.on('beforeRender', function(e) {
e.preventDefault();
console.log('beforeRender event triggered 2!');
demo.on('beforeRender', function(e) {
console.log('beforeRender event triggered 3!');
demo.render();
在这个测试了， 我定义了一个跟DOM相关的Demo组件并继承了EventBase这个事件管理的类，给beforeRender事件添加了3个监听，其中一个有加prevetDefault()的调用，而且该回调还不是最后一个，最后的测试结果是：
从结果可以看到，render方法的主要逻辑代码跟后面的render事件都没有执行，所有beforeRender的监听器都执行了，说明e.preventDefault()生效了，而且它没有对beforeRender的事件队列产生影响。
2）模拟跟DOM无关联的普通对象
测试代码一：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('mod/class');
var EventBase = require('mod/eventBase');
var Demo = window.demo = Class({
instanceMembers: {
init: function (options) {
this.base();
//添加监听
this.on('beforeRender', $.proxy(options.onBeforeRender, this));
this.on('render', $.proxy(options.onRender, this));
render: function () {
//触发beforeRender事件
var e = $.Event('beforeRender');
this.trigger(e);
if(e.isDefaultPrevented())return;
//主要逻辑代码
console.log('render complete!');
//触发render事件
this.trigger('render');
extend: EventBase
var demo = new Demo({
onBeforeRender: function(e) {
console.log('beforeRender event triggered!');
onRender: function(e) {
console.log('render event triggered!');
demo.render();
在这个测试里， 我定义了一个跟DOM无关的Demo组件并继承了EventBase这个事件管理的类，给beforeRender事件和render事件都添加了一个监听，render方法中也有打印信息来模拟真实的逻辑，最后的测试结果是：
完全与预期的一致。
测试代码二：
define(function(require, exports, module) {
var $ = require('jquery');
var Class = require('mod/class');
var EventBase = require('mod/eventBase');
var Demo = window.demo = Class({
instanceMembers: {
init: function (options) {
this.base();
//添加监听
this.on('beforeRender', $.proxy(options.onBeforeRender, this));
this.on('render', $.proxy(options.onRender, this));
render: function () {
//触发beforeRender事件
var e = $.Event('beforeRender');
this.trigger(e);
if(e.isDefaultPrevented())return;
//主要逻辑代码
console.log('render complete!');
//触发render事件
this.trigger('render');
extend: EventBase
var demo = new Demo({
onBeforeRender: function(e) {
console.log('beforeRender event triggered!');
onRender: function(e) {
console.log('render event triggered!');
demo.on('beforeRender', function(e) {
e.preventDefault();
console.log('beforeRender event triggered 2!');
demo.on('beforeRender', function(e) {
console.log('beforeRender event triggered 3!');
demo.render();
在这个测试了， 我定义了一个跟DOM无关的Demo组件并继承了EventBase这个事件管理的类，给beforeRender事件添加了3个监听，其中一个有加prevetDefault()的调用，而且该回调还不是最后一个，最后的测试结果是：
从结果可以看到，render方法的主要逻辑代码跟后面的render事件都没有执行，所有beforeRender的监听器都执行了，说明e.preventDefault()生效了，而且它没有对beforeRender的事件队列产生影响。
所以从2个测试来看，通过改造后的EventBase，我们得到了一个可以让任意对象支持jquery事件管理机制的方法，将来在考虑用事件机制来解耦的时候，就不用再去考虑前面第一个介绍的发布-订阅模式了，而且相对而言这个方法功能更强更稳定，也更符合你平常使用jquery操作DOM的习惯。
4. 本文小结
有2点需要再说明一下的是：
1）即使不用jquery按照第1部分最后提出的思路，把第一部分常规的发布-订阅模式改造一下也可以的，只不过用jquery更加简洁些；
2）最终用jquery 的事件机制来实现任意对象的事件管理，一方面是用到了代理模式，更重要的还是要用发布-订阅模式，只不过最后的这个实现是由jquery帮我们把第一部分的发布-订阅实现改造好了而已。
最后真切地希望这篇分享能够给你的工作带来一些帮助，谢谢阅读：）
自定义事件的名称，有的时候会跟jquery内部的一些事件名称冲突，我遇到一种情况：定义一个跟DOM关联的组件时，我用到了一个自定义事件remove，当我调用this.trigger('remove')的时候，竟然把这个组件关联DOM元素从DOM中删除了，估计这个事件名称已经在jquery内部使用，当在DOM元素上触发这个事件后，会导致元素remove。所以当你碰到类似的意外情况时，回头想想自定义事件的名称是不是跟jquery某些API有关联，然后试试换一个名称是不是就能解决问题。
阅读(...) 评论()