一個 JS 框架需要做什么
原文 http://segmentfault.com/a/1190000003505612
學習再多，也是杯水車薪。
為什么這么說？不知道各位有沒有發現，雖然前端發展快，但一些有名的框架至少會火熱很長時間，比如 Backbone、React、Ember 。如果有心要學，肯定有足夠的時間把它學會，畢竟事實擺在面前，很多公司的上線產品就是用 React 來寫的，比如 Teambition 的簡聊，貌似它是從 Backbone 重構過來的。然而，很多同學在接手新項目時，常常會不知所措，不知道用什么技術去做，或者說，只依賴于擅長的技術，就算在一些場景中它可能并不是最適合的。
因為這些同學平時不夠努力嗎？不是吧。他們可能會看書到很晚，瀏覽很多博客，就是為了去了解 CORS 的應用，或者是想知道為什么 Angular 中的 scope 在某些時候不能雙向綁定了。對，時間是花了，但遇到問題還是一頭霧水。可能前端就是這么一份工作吧，慫恿你去學游泳，蛙泳、自由泳、蝶泳，海嘯來了照樣被沖走……
那這篇文章要說的是什么呢？就是假設你現在什么都沒學，就靠基本功，去完成一個靜態頁面，當然也有業務邏輯，包括數據的 CRUD、動畫，怎么做？有個關于 VanillaJS 的梗不知道大家看過沒，你一定會會心一笑的。
沒有 jQuery 了，沒有 Bootstrap 了，扔掉所有你引以為傲的武器，但大惡魔 IE 6 還在。具體的需求不給了，反正給了你們也不會照著去實現，真有心要做的話，可以做一個 todo app 吧。
DOM 查詢
在沒有第三方框架可以用的時候，如果真的按照功能列表，從第一條實現到最后一條，每個模塊用自執行匿名函數包起來，所有代碼寫在一個文件中，看上去十分合理，但真這么做的話，恐怕你會瘋掉吧。哦，好處是你可以跟別人吹噓今天寫了三四百行代碼，產量很高呢！
所以，不使用第三方框架，我們可以自己寫，它的功能只要符合應用場景就可以了，不用去考慮各種不會發生的奇葩情況。
好，開始。我們最依賴的功能是通過 CSS 選擇器獲取相應的 DOM 元素，這里只使用兼容性最高的方式，就是 id 和元素名選擇器。
var idRegex = /^#[\w\-]+/i,
tagRegex = /^[a-z]+/i;
function query(selector, context) {
context = context || document;
if (idRegex.test(selector)) {
return document.getElementById(selector.substring(1));
} else if (tagRegex.test(selector)) {
return context.getElementsByTagName(selector);
}
return null;
}對了，我把所有 DOM 操作放在了 F.DOM 命名空間下，所以是這樣使用 query 方法的：
F.DOM.query('#id');的確比 jQuery 的 $('#id') 方式麻煩很多，但“子不嫌母丑，狗不嫌家貧”，自己寫的代碼，再爛也要用下去。
另外一些必須的操作就不把代碼貼出來了，比如說 addClass、removeClass、hasClass 等。
DOM 事件
如果有同學參加過面試的話，我想“怎么去監聽一個 DOM 事件？請盡可能考慮瀏覽器兼容性”這個問題是經常會問到吧。這兒寫一個可行方案吧。
// 監聽 DOM 事件
function addEventListener(el, event, handler, useCapture) {
if (el.addEventListener) {
el.addEventListener(event, handler, useCapture);
} else if (el.attachEvent) {
el.attachEvent('on' + event, handler);
} else {
// not support
}
}
// 取消 DOM 事件
function removeEventListener(el, event, handler, useCapture) {
if (el.removeEventListener) {
el.removeEventListener(event, handler, useCapture);
} else if (el.detachEvent) {
el.detachEvent('on' + event, handler);
} else {
// not support
}
}我知道大家可能有更好的，或者更完善的方案，但抱歉這里討論的重點不是它。
關于 DOM 事件方面，還有一些有用的方法，比如 preventDefault 和 stopPropagation 也可以自己去封裝一下。然后這兒想討論一下 DOM 加載完成的事件。jQuery 中我們會這么用：
$(function() {
// ready
});如果我們也想封裝一個類似的方法，可能會這么寫：
addEventListener('window', 'load', callback);可是 load 事件是在什么情況下觸發的呢？當頁面上的所有資源，包括圖片，加載完之后才觸發！也就是說，如果圖片很多，網速很慢，那觸發 load 要花很長時間。在本地調試時不會有這種延遲的問題，所以往往會被忽略。
那怎么改正呢？第一，可以把 <script> 放到 <body> 中所有元素的下方，就不需要監聽任何“加載完成”的事件了。第二，監聽 DOMContentLoaded 事件，IE 9+ 支持。至于如何兼容低版本瀏覽器，可以看 這篇文章 (addDOMLoadEvent) 。
組件式開發
“組件”這個詞其實來源于很多框架，比如 Backbone 中的 View，React 就更不用說了，它為了組件化專門規定了 JSX（當然它有更宏偉的 goal） 。我們這里討論的組件也是差不多的意思，就是按照功能，把頁面上分成一個個獨立的模塊，模塊之間通過消息（事件）進行溝通。關于模塊耦合，JSX 是通過類似于 HTML 標簽嵌套的方式來表現的，而我們自然沒這么高級，就直接把依賴的模塊注入到其他模塊中，比如：
/**
* 應用頂層，構造一些頁面中用到的組件
*/
function App() {
F.Component.call(this);
}
App.prototype = new F.Component();
F.extend(App.prototype, {
constructor: App,
init: function() {
this._blogPost = new BlogPost('#blog-post');
this._blogList = new BlogList('#blog-list', this);
this._newsList = new NewsList('#news-wrapper');
}
});
new App();其中，BlogPost 是發布日志的組件，BlogList 是日志列表。發布日志后必然會顯示到列表中，所以在構造日志列表時，會把 BlogPost 注入到 BlogList 中。
每個組件可以提供一個 id 選擇器，表示該組件需要繪制在哪個元素內。
消息傳播機制
關于 BlogPost 和 BlogList，大家可以想象微博的主頁，它上面是一個發布框，下面是微博列表，就是這樣一個界面。
當微博發布之后，列表中需要增加新發布的內容，這個過程是誰給誰發消息？按照面向對象的思想，應該是類似于這樣：
// 在 發布框組件 中調用 列表組件 的方法
blogList.add(item);顯然是 BlogPost 依賴于 BlogList 對嗎？但貌似我們上面的代碼不是這個邏輯，而是反過來。那么實際情況就成了這樣：
// 發布框：BlogPost 中觸發事件
this.emit('add', item);
// 列表：BlogList 中監聽事件
this.listenTo(blogPost, 'add', handler);
// 由 handler 處理發布事件嗯，代碼變多了，看來得強行圓回來。
為什么我強烈建議使用后者？假設過了一段時間，某個充滿創意的策劃突然告訴你，當發布微博之后，可以顯示到朋友圈（假設有這么個東西）。那么前者的方式會怎么做？是不是首先給這個發布框多注入一個依賴，即朋友圈，然后調用朋友圈的某個方法？
如果再過段時間，又有新創意了，是不是又得給發布框加依賴了？最后搞得發布框依賴于微博列表、依賴于朋友圈、依賴于其他 8 個組件，真不想用水性楊花來形容它。
這個問題很常見吧？如果用消息機制的方式就會好很多，只需要在新增加的組件中監聽發布框的 'add' 事件就可以了。
如果你能接受這個方式，可能想知道怎么去簡單地實現它。
var Event = F.Event = function Event() {
// 該組件相關的所有的事件都保存在 _events 對象中
// 格式 - {'eventName': [{handler, context}*]}
this._events = {};
};
F.extend(Event.prototype, {
// 監聽事件
on: function(event, handler, context) {
if (!this._events[event]) {
this._events[event] = [];
}
this._events[event].push({
handler: handler,
context: context || this
});
},
// 觸發事件
emit: function(event) {
var events = this._events[event] || [],
args = [];
// 第一個參數為事件名，后面的參數需要傳給處理該事件的方法，記錄到 args 中
if (arguments.length > 1) {
args = slice.call(arguments, 1);
}
// 回調時需要傳入參數
events.forEach(function(v) {
v.handler.apply(v.context, args);
});
}
}把重點部分貼了一下。第一，這個 Event 是所有組件的基類，所以每個組件都有 on 和 emit 方法。第二，F.extend 的作用就是把后面對象的方法和屬性直接賦值給第一個，extend 的意思是“擴展”而不是“繼承”，這點別混淆了。第三，通過改變上下文（就是 this），當一個組件的事件觸發時，由另一個組件處理。
由于上面省略了很多代碼，一般還要考慮的情況有，怎么取消監聽，怎么實現例子中的 listenTo 等。
組件繼承
關于繼承，這篇文章略有提到（4.2 通過 prototype 實現繼承）。
這里就寫個 F.extend 技巧好了。一般來說，會在繼承之后修改 prototype 的 constructor 屬性，并在它上面定義很多方法，就變成了：
A.prototype = new B();
A.prototype.constructor = A;
A.prototype.f1 = function() {};
A.prototype.f2 = function() {};大家不妨去實現一個 extend 方法，讓代碼變成：
A.prototype = new B();
extend(A.prototype, { /* 原型上的方法和屬性 */ });DOM 事件代理
一個組件往往會對應一個頁面區域，那在這個區域上會有單擊按鈕等一些 DOM 事件。由于在初始化組件時，這些元素還沒有追加到 DOM 上去，所以就不能使用 addEventListener 這個方法來監聽單擊事件。那要怎么監聽呢？
兩種方法。一，在生成 HTML 片段時，設置元素的 onclick 屬性，比如：
container.innerHTML = '<a href="#" onclick="delegate(' + id + ')">click</a>';技巧在于，這個 delegate 方法是全局的，并且它能通過組件的 id 來找到對應的組件對象，再調用該組件的回調函數。
二，在子元素添加到 DOM 之前，父容器是存在了的，所以可以對父容器監聽 click 事件，然后對 event.target 判斷。
addEventListener(container, 'click', delegate)無論是哪種方法，具體實現時肯定會碰到問題，這些都是預期范圍內的，所以不用沮喪。
封裝 AJAX
同樣地，面試官極有可能問你“請用原生 JS 封裝 AJAX 的 GET 請求”。你應該已經熟稔于心，或者至少有筆記記錄了怎么寫。
現在要討論的是，如何利用“消息機制”去避免回調。jQuery 中的 ajax 方法需要一個 success 的回調，加上配置 url 等信息，導致完成一次請求所用到的代碼非常復雜，很難閱讀。ES 6 推出了 Promise，使得我們可以用同步的語法去做異步的事，閱讀性得到了提升。
由于我們不能用 Promise，所以就發消息吧，也很優雅。
F.extend(Request.prototype, {
constructor: Request,
get: function() {
var xhr = createXHR(),
self = this;
xhr.open('GET', this._api, true);
xhr.onreadystatechange = function() {
if (xhr.readyState === 4 && xhr.status === 200) {
self.emit('success', xhr.responseText);
}
};
xhr.send();
}
});代碼并不全，說明一下，Request 繼承自 Event，構造時需要傳入一個 url，表示請求的地址。用法類似于：
// 在某個組件中，this 指向該對象的實例
var r = new Request('http://www.example.com/blogs');
r.get();
r.on('success', callback, this);貌似有點像 Angular 中 new Resource(url); 的用法。
功能性兼容 (Polyfill)
這部分主要是為了兼容比如說 IE 6 不支持 HTML5 元素的樣式、數組中的高級用法（forEach 和 map 等）、字符串的高級用法（trim）、Function 的 bind 等。
因為是臨時編寫的框架，所以業務邏輯的代碼中需要什么，就補什么。
兼容 HTML5 元素你可以這么做，很簡單：
document.createElement('header');把所有用到的元素都 createElement 一遍就行了，這段代碼必須放在 <head> 中。
至于兼容 forEach、map、bind 這一些，網上應該有一大堆吧，這兒只是為了提醒各位去考慮這些方面。然后，網上的兼容策略可能很復雜，沒必要，大家完全可以嘗試自己去寫，“過早的優化是萬惡之源”（這是個人最喜歡的名言了）。
淺談模板語言
這個雖然不是必須的，并且在我目前寫的代碼中也沒有考慮到，但經過一位高人提醒，就覺得，咦，很多聽上去高大上的技術，從原理來講都是柴米油鹽這些基礎知識。
如果各位之前對 underscore 中的 _.template 方法并不了解，看完這節應該會幫助你一些。
假設要生成一個用戶名的鏈接，用模板可以這么寫：
<a href="#">{{ name }}</a>而用現在的方式是這么做的：
var html = '<a href="#">' + model.name + '</a>';那么怎么通過模板的方式去做，不用費勁地拼接字符串呢？答案是正則。
function parse(template, model) {
return template.replace(/\{\{\s*(.+?)\s*\}\}/g, function(match, p1) {
return model[p1] || match;
});
}替換時，match 表示由正則匹配到的字符串，這里是 '{{ name }}'，p1 表示匹配到的字符串中第一個組的值，這里是 'name'，問號 ? 是阻止貪婪匹配，最后由返回值替換 match，這里是 model.name 。
小結
文章中的代碼可能只展示了一小部分，因為我主要是想說明一些值得考慮的點，并不是教程，至少大家可以用這些作為草稿去開始。
繞來繞去，JS 中的語法也屈指可數，那為什么在學習新技術的時候會很焦灼呢？基礎是一個原因，沒有基礎就造不了任何建筑；知識面是另一個，解決問題時最怕的是不知道有某個答案存在，使用 API 時最討厭的就是不知道它已經提供這個功能了。所以平時應該多看一些文章，有想法就記下來，無論是筆記的方式還是博客的方式都行，寫博客可以強迫你把想法表達出來，這跟“看懂”是不一樣的。
至于學習的性價比，我只能說，不要停！
你可能覺得，唉，React 是很好，但眼下又用不到，就算學了也沒用，還不如把時間花在績效上。自己寫代碼永遠是個封閉的空間，包括因為遇到什么問題被動地去 google 也好，如果不是主動去看新鮮事物，能力的增長是十分緩慢的。為什么會不斷有新技術產生？這個事情本身就在告訴我們，需要用新的角度去解決新的問題（或者舊的）。舉兩個例子，IE 在 Windows 系統上是不會自動更新的，現在它死了（Windows 10 Edge）；Adobe Flash 適應不了移動平臺，而安全漏洞又頻出，現在它馬上要死了（Adobe 的高層表示并不 care，因為 Flash 只占很少一部分營收）。
互聯網它不跟你講人情的，適者生存。