[書籍精讀]《基於MVC的JavaScript Web富應用開發》精讀筆記分享

寫在前面

• 書籍介紹：《JavaScript異步編程》講述基本的異步處理技巧，包括PubSub、事件模式、Promises等，經過這些技巧，能夠更好的應對大型Web應用程序的複雜性，交互快速響應的代碼。理解了JavaScript的異步模式可讓讀者寫出結構更合理、性能更出色、維護更方便的JavaScript程序。
• 個人簡評：js異步編程的科普小書，內容比較全面但不夠深刻。做爲前端開發，瞭解異步處理機制和優化異步代碼很是重要，特別推薦一下《JavaScript異步編程》。
• ！！福利：文末有pdf書籍、筆記思惟導圖、隨書代碼打包下載地址哦
  

第一章 深刻理解JavaScript事件

1.1.事件的調度

• JavaScript代碼用於不會被中斷，由於代碼在運行期間只須要排隊事件便可，而這些事件在代碼運行結束以前不會被觸發

1.2.異步函數的類型

• 每一種JavaScript環境都有本身的異步函數集
• 在瀏覽器端，Ajax方法有一個可設置爲false的async選項
• 在Node.js中同步的API方法在名稱上會有明確的標示如fs.readFileSync
• WebKit的console.log打印輸出並無當即拍攝對象快照，只存儲了一個指向對象的引用，等代碼返回事件隊列纔去打印輸出快照
• Node的console.log是嚴格同步的
• 當同一個JavaScript進程正運行着代碼時，任何JavaScript計時函數都沒法使其餘代碼運行
• setInterval調度事件設置成0，chrome等瀏覽器觸發頻率大約爲200次/秒，node大約是1000次/秒
• 替換成while循環時在Chrome中觸發頻率達到400萬次/秒，在node中會達到500萬次/秒
• 須要更細粒度的計時，在node中使用process.nextTick，在現代瀏覽器中使用requestAnimationFrame(主意兼容性)

1.3.異步函數的編寫

• 要想確認某個函數異步與否，惟一的方法就是審查其源代碼
• 有些函數某些時候是異步的，但其餘時候卻不是
• 大量延時的話，會形成巨大的計算荷載
• 異步遞歸有一點很懼怕，即在等待任務完成期間，可觸發延時的次數是不受限的
• 永遠不要定義一個潛在同步而返值卻有可能用於回調的函數

1.4.異步錯誤的處理

• JavaScript也容許拋出異常，隨後再用一個try/catch語句塊捕獲
• 正因如此，Node.js中的回調幾乎老是接受一個錯誤做爲其首個參數，這樣就容許回調本身來決定如何處理這個錯誤
• 始終記住，只能在回調內部處理源於回調的異步錯誤
• 在瀏覽器環境中，windows.onerror能夠捕獲異常，若是返回true，則能阻止瀏覽器默認的錯誤處理行爲
• 在node中，相似的process對象的uncaughtException事件捕獲錯誤，正常狀況下，node應用會因未捕獲的異常而當即退出
• 但自Node0.8.4起，uncaughtException事件就被廢棄了
• domain對象是事件化對象，它將throw轉化爲error事件

1.5.嵌套式回調的解嵌套

• 最多見的反模式作法是，回調內部再嵌套回調
• 嵌套式回調誘惑咱們經過添加更多代碼來添加更多特性，而不是將這些特性實現爲可管理、可重用的代碼片斷
• 按照慣例，請避免兩層以上的函數嵌套

第二章 分佈式事件

• 但願使用分佈式事件：事件的蝴蝶偶然扇動下翅膀，整個應用處處都引起反應
• PubSub意爲發佈/訂閱，模式來分發事件
• PubSub模式的一些具體表現：Node的EventEmitter對象，Backbone的事件化模型，JQuery的自定義事件

2.1.PubSub模式

• Node中幾乎全部的I/O都是EventEmitter對象：文件流、HTTP服務器，甚至是應用進程自己
• 事件處理器自己沒法知道本身是從事件隊列中仍是從應用代碼中運行的
• 對於無需即刻發生的事情維持一個隊列，並使用一個計時函數定時運行此隊列中的下一項任務
• PubSub簡化了事件的命名、分發、堆積

2.2.事件化模型

• 只要對象帶有PubSub接口，就能夠稱之爲事件化對象
• 每次一個對象上的事件引起了一系列事件並最終對這個對象自己觸發了相同的事件，結果就事件循環了
• 事件化模型爲咱們帶來了一種將應用狀態變化轉換爲事件的直觀方式

2.3.jQuery自定義事件

• jQuery簡化了強大分佈式事件系統向任何Web應用程序的移植
• jQuery提供了非冒泡式的triggerHandler方法
• jQuery的自定義事件容許直接經過DOM來表達DOM相關的事件，沒必要再把DOM變化的狀態複製到應用程序的其餘地方

小結

• PubSub模式尤爲不適合一次性事件
• 用於解決一次性事件問題的工具叫作Promise

第三章 Promise對象和Deferred對象

3.1.Promise極簡史

• Promise對象也和EventEmitter對象同樣，容許向同一個事件綁定任意多個處理器(堆積技術)
• 使用Promise對象的最大優點在於，能夠輕鬆從現有Promise對象派生出新的Promise
• 在通常性用法中，Promise、Deferred和Future這三個詞大致可算做同義詞

3.2.生成Promise對象

• 準確的說，Deffered是Promise的超集，它比Promise多一項關鍵特性，能夠直接觸發
• 重申一點：每一個Deferred對象都含有一個Promise對象，而每個Promise對象都表明者一個Deferred對象
• Ajax是演示Promise的絕佳用例：每次對遠程服務器額調用都或成功或失敗，而咱們但願以不一樣的方式來處理這兩種狀況

3.3.向回調函數傳遞數據

• 執行或拒絕Deferred對象時，提供的任何參數都會轉發至相應的回調
• resolve/reject能夠直接將其上下文傳遞至本身所觸發的回調

3.4.進度通知

• jQuery1.7中爲Promise對象新添了一種能夠調用無數次的回調progress
• 總結下，Promise對象接受3種回調形式：done、fail、progress

3.5.Promise對象的合併

• Promise對象的邏輯合併技術有一個最多見的用例：斷定一組異步任務什麼時候完成

3.6.管道鏈接將來

• JavaScript中經常沒法便捷的執行一系列異步任務，一個主要緣由是沒法在第一個任務結束以前就向第二個任務附加處理器
• jQuery1.6爲Promise對象新增pipe(管道)方法
• promise.promise() === promise

3.7.jQuery與Promises/A的對比

• jQuery使用resolve做爲fail的反義詞，而Promise/A使用的是fulfill。在Promise/A規範中，Promise對象不論是已履行仍是已失敗，都是已執行

3.8.用Promise對象代替回調函數

• 理想狀況下，開始執行異步任務的任何函數都應該返回Promise對象
• Promise大大有助於讓意大利麪式的回調趨於平滑，並且也是由於Promise能夠很是輕鬆的協調這種類型的異步任務

第四章 Async.js的工做流控制

4.1.異步工做流的次序問題

• 普通的異步代碼根本沒法保證按照作出調用次序來觸發調用的回調

4.3.Async.js的任務組織技術

• Async.js的數據收集方法解決了一個異步函數如何運用於一個數據集的問題
• 異步函數序列的運行：async.series和async.waterfall
• 便利的是Async.js按照任務列表的次序向完工事件處理器傳遞結果，而不是按照生成這些結果的次序
• Async.js的內核與靈魂：爲最多見的異步情景提供簡單又省時的工具函數

4.4.異步工做流的動態排隊技術

• async.queue的底層基本理念使人想起DMV動態管理視圖

第五章 worker對象的多線程技術

5.0.寫在前面

• 事件可以代替一種特殊的多線程，即應用程序進程可拆分紅多個部分同時運行的多線程技術（或者經過中斷技術虛擬實現，或者經過多個CPU內核真正實現）
• 儘管只運行在一個線程上確實不理想，但天真的將應用直接分發給多個內核更加糟糕
• 與不一樣線程進行交互的方式與在JavaScript中進行I/O操做一摸同樣
• 同一個進程內的多個線程之間能夠分享狀態，而彼此獨立的進程之間則不能
• 在JavaScript環境中，由worker對象運行的併發代碼歷來不會分享狀態

5.1.網頁版的worker對象

• 首要目標，在不損害DOM響應能力的前提下處理複雜的計算
• 幾種潛在用法：解碼視頻、加密通訊、解析網頁式編輯器
• 基於相似的理由，worker對象看不到全局的window對象和主線程及其餘worker線程的任何對象
• 經過postMessage發送的對象會透明的作序列化和反序列化，想一想JSON.parse與JSON.stringify
• worker對象能夠隨意使用XMLHttpRequest
• 還有一個importScripts函數能夠同步加載並運行指定的腳本

5.2.cluster帶來的Node版worker

• node0.6後推出一個支持多個進程綁定同一個端口的API:cluster（羣集）
• 一般爲追求最佳性能而使用cluster按每顆CPU內核分化出一個進程
• Node版worker對象由cluster.fork()把運行本身的同一個腳本再次加載成一個獨立的進程
• 瀏覽器能夠將任意多餘的線程降格爲後臺任務，而node服務器則要留出計算資源保障其請求處理的主要任務
• 最著名的魔法：多個worker對象試圖監聽一個TCP端口時，node利用內部消息來容許分享該端口
• 一樣，cluster對象有一個主線程和多個worker線程，之間基於一些帶有序列化對象或附連字符串的事件
• 爲了儘量減小線程之間的通訊開銷，線程間分享的狀態應該存儲在像Redis這樣的外部數據庫中

第六章 異步的腳本加載

• 須要對腳本分而治之，那些負責讓頁面更好看、更好用的腳本應該當即加載，而那些能夠待會再加載的腳本稍後加載

6.1.侷限性與補充說明

• 請儘可能避免使用內聯技術
• 請勿使用document.write
• 只要知道document.write至關於操控DOM時的GOTO語句就好了

6.2.script標籤的再認識

• 現代瀏覽器中的script標籤分紅了兩種新類型：經典型和非阻塞型
• 流行將腳本放在頁面body標籤的尾部。一方面用戶能夠更快的看到頁面，另外一方面能夠主動親密接觸DOM而無需等待事件來觸發本身
• defer讓咱們想到靜靜等待文檔加載的有序排隊場景，那麼async就會讓咱們想到混亂的無政府狀態
• 一個腳本即用defer又用async，則在那些同時支持的瀏覽器中，async會覆蓋defer

6.3.可編程的腳本加載

• 兩種合理的方法來抓取並運行服務器腳本：生成Ajax請求並用eval函數處理響應；向DOM插入script標籤
• require.js強大的工具包可以自動和AMD技術一塊兒捋順哪怕最複雜的腳本依賴圖
• 若是要求根據條件來加載腳本，請考慮像yepnope這樣的腳本加載器。若是站點大量相互依賴的腳本，請考慮require.js

寫在後面

• pdf書籍、筆記思惟導圖、隨書代碼打包下載地址：https://pan.baidu.com/s/1WMzAciLMfTasiWFQjz4ftA（提取碼：wd01）
• 紙質書京東購買地址：https://u.jd.com/e0BT68（推薦使用紙質書來學習）
• 爲了方便在手機上查看，後面我會把這些筆記陸續發佈到公衆號「派三派四」，能夠掃碼關注一下，歡迎關注。