摘要：這部分比較容易讓人產生疑惑的是循環部分，這個循環有什么用呢舉個例子以上代碼是最簡單的情況，監聽事件，當變化時，打印出在源碼中，當第一次進入后，緊接著被置為，而事件觸發回調函數也不會更改的值，因此再次判斷時條件不成立，內的代碼段只會執行一次。

本文已同步在我的博客

在這個react和vue如日中天、jquery逐漸被大家拋棄的年代，我還是想要來說一說backbone。

16年6月初，在沒有任何前端框架使用經驗、js水平也較一般的情況下，被告知需要在幾個工作日內搭建完成一個后臺管理系統，沒有頁面設計稿、沒有組件庫，一切都是從零開始。當時面臨兩個選擇，backbone和react。雖然我很希望能夠拿react來練手，但是考慮到學習成本和項目時間問題，leader還是建議我使用backbone來完成，就這樣，一直用到差不多現在。雖然到項目后期業務場景越來越復雜，backbone的這套技術棧體現出越來越多的問題，但是對于小型項目來說，我還是認為backbone是個不錯的選擇，而且學習成本低，上手極快~

backbone是個非常輕量的mvc庫，本文將基于backbone的源碼談一談其實現的核心部分，以及其中一些巧妙的思想和代碼實現技巧。

事件部分的核心邏輯其實比較簡單，簡化一下可以用如下的偽代碼來表示：

var events = {
    evt1: handlers1,
    evt2: handlers2,
    ...
}

//注冊事件
function on(name, callback) {
    const handlers = events[name] || (events[name] = []);
    handles.push(callback);
}

//觸發事件
function trigger(name) {
    if (!events[name]) {
        return;
    }
    const handlers = events[name];
    for (let i = 0, len = handlers.length; i < len; i++) {
        handlers[i]();
    }
}

//解除綁定
function off(name) {
    delete events[name];
}

當然了，以上寫法有很多細節的地方沒有加入進來，比如上下文綁定、對多種傳參方式的支持、觸發事件時對事件處理器傳參的處理等等。

我們知道，對于MVC來說，M（模型）的變化會反映在V（視圖）上，實際上是視圖監聽了模型的變化，再根據模型去更新自身的狀態，這當中最重要的一個功能就是監聽（listen）。該功能也是由Events部分實現的，包括：listenTo、stopListening等

listenTo和on類似，都是監聽一個事件，只不過listenTo是監聽其他對象的對應事件，而on是監聽自身的對應事件。stopListening同理。比如：

a.on("testevent", function(){
    alert("1");
});
a.trigger("testevent");

如果其他對象希望監聽a的testevent事件呢？則可以通過listenTo來實現：

b.listenTo(a, "testevent", function() {
    alert("catch a"s testevent");
})

其中第一個參數為要監聽的對象，第二個參數為事件名稱

當調用on方法的時候，會為對象自身創建一個_event屬性；而調用listenTo方法時，會為監聽對象創建_event屬性，同時為了記錄監聽者，被監聽對象還會創建一個_listeners屬性：

a.on("testevent", handlers1);

a會變成：

{
    _events: {
        testevent: [handlers1]
    },
    on: function() {
        //...
    }
    ...
}

當有其他對象監聽a時，如：

    b.listenTo(a, "testevent", handlers2);

a會變成：

{
    _events: {
        testevent: [handlers1, handlers2]
    },
    _listeners: b,
    on: function() {
        //...
    }
    ...
}

在事件機制的實現部分，除了核心邏輯之外，在對一些方法的使用上，也很考究。為了綁定函數執行的上下文，我們經常會使用apply，call這些方法，而源碼中多次提到apply的執行效率要低一些，因此，有這樣的實現：

// A difficult-to-believe, but optimized internal dispatch function for
// triggering events. Tries to keep the usual cases speedy (most internal
// Backbone events have 3 arguments).
var triggerEvents = function(events, args) {
    var ev, i = -1, l = events.length, a1 = args[0], a2 = args[1], a3 = args[2];
    switch (args.length) {
      case 0: while (++i < l) (ev = events[i]).callback.call(ev.ctx); return;
      case 1: while (++i < l) (ev = events[i]).callback.call(ev.ctx, a1); return;
      case 2: while (++i < l) (ev = events[i]).callback.call(ev.ctx, a1, a2); return;
      case 3: while (++i < l) (ev = events[i]).callback.call(ev.ctx, a1, a2, a3); return;
      default: while (++i < l) (ev = events[i]).callback.apply(ev.ctx, args); return;
    }
};

有關為什么call比apply的效率更高的解釋可以參考這篇文章

model用于維護數據，其中最關鍵的是對數據的更新部分，即set

// Trigger all relevant attribute changes.
if (!silent) {
    if (changes.length) this._pending = options;
    for (var i = 0; i < changes.length; i++) {
        this.trigger("change:" + changes[i], this, current[changes[i]], options);
    }
}

// You might be wondering why there"s a `while` loop here. Changes can
// be recursively nested within `"change"` events.
if (changing) return this;
if (!silent) {
    while (this._pending) {
        options = this._pending;
        this._pending = false;
        this.trigger("change", this, options);
    }
}
this._pending = false;
this._changing = false;
return this;

每次set數據的時候，根據數據變化的部分，使用trigger方法觸發相應的事件；在set數據時，如果不希望觸發change事件，可以設置silent為true。

這部分比較容易讓人產生疑惑的是while循環部分，這個while循環有什么用呢？舉個例子：

new Model.on("change", function() {
    console.log("model change");
}).set({
    a: 1
});

以上代碼是最簡單的情況，監聽change事件，當model變化時，打印出model change
在源碼中，當第一次進入while后，緊接著this._pending被置為false，而事件觸發回調函數也不會更改this._pending的值，因此再次判斷時條件不成立，while內的代碼段只會執行一次。

但是實際情況往往不是這么簡單，如代碼注釋中所說，有可能會有嵌套的情況，比如：

new Model.on("change", function() {
    this.set({
        b: 1
    })
}).set({
    a: 1
});

在這種情況下，第一次trigger觸發change的回調函數中，又再次對model進行了更新操作，

this.set({
    b: 1
})

每次set時，會更新this._pending為true，這樣當set b后，就會再次進入while內，觸發change事件。而如果沒有使用while循環的話，對b屬性更新的操作就無法觸發change事件，導致其監聽者到無法根據最新的數據更新自身狀態。

View部分的實現比較簡單，其中最主要的是events部分，通常在一個View中，都會綁定一些dom事件，比如：

{
    "click .preview-btn": "preview",
    "click .save-btn": "save"
}

主要有兩點需要說明：

backbone中是采用的事件委托的方式綁定事件，因此，一些不冒泡的事件，比如scroll，是無法通過這樣的方式綁定的

回調函數會保持正確的this指向。backbone內部進行了處理

delegateEvents: function(events) {
    events || (events = _.result(this, "events"));
    if (!events) return this;
    this.undelegateEvents();
    for (var key in events) {
        var method = events[key];
        if (!_.isFunction(method)) method = this[method];
        if (!method) continue;
        var match = key.match(delegateEventSplitter);
        this.delegate(match[1], match[2], _.bind(method, this));
    }
    return this;
}

以上部分介紹了backbone中最核心部分的實現機制。可以看到其實現非常的簡單，但是對于小型項目來說，確實可以幫我們做一些對數據的維護和管理工作，提高開發效率。但是隨著業務逐漸復雜，會越來越發現，backbone所能做的實現有限，而對于數據維護部分也非常不方便，尤其是需要是對多個模塊間的通信和數據維護問題。后續我會結合在復雜業務中的使用談一談backbone的缺點，以及更優的框架能帶來的便利。

說句題外話，雖然去年由于時間原因選擇了backbone，這一年基本沒有在復雜業務場景中使用react技術棧，都是自己做個小demo練手。但是也正是因為有了使用backbone去寫復雜業務的經歷，在數據維護上和模塊間通信上非常麻煩，以及backbone渲染dom時直接全部更新的會導致的頁面渲染性能問題，才更讓我感覺react + redux的美好。知其然，還需知其所以然啊~ ~
不然我覺得我可能會一直疑惑為什么要用一套這么復雜的技術棧，異步請求這塊寫起來還那么麻煩。這么看，壞事也算是好事了吧~~