JS不同層的職責和API

1. 瀏覽器低層分層大概也可以分為DOM / BOM / STYLE 樣式 /Canvas 2D / WebGL / SVG

瀏覽器底層面臨的一些問題

1. JS核心語法層面薄弱
2. JS原生API不好用 （ajax , cookie ,）
3. 瀏覽器相容問題 （IE9微軟用了自己一套的東西，搞事情？）

對過時瀏覽器的相容性問題是沉重的知識包袱， 關鍵是這種知識沒有延續性，會影響你學習和使用新技術

框架core

Prototype,YUI,Dojo,jquery

框架元件

封裝瀏覽器原生API，抽象成元件

input text checkbox radio select
 

沒有日曆選擇器，富文字編輯器，Excuse me?

• 框架元件->高度重用
  
  • 獨立元件底層（原生js層，不用依賴框架）
  • 定製元件（小白->大牛寫）
  • 框架通用元件（大牛寫）

元件定義和載入

js部分
var H5ComponentBase = function (name,cfg ) {屬性+方法}

css部分
啪啪啪啪啪啪（一陣敲鍵盤聲音）

然後引入檔案，例項化物件

var cfg = {引數}
var h5 = new H5ComponentBase('bob',cfg);
            $('.iphone').append(h5);
 

多個元件打架（變數衝突）

解決方法：

• css通過加字首形成名稱空間（tab_view）
• JS在函式內部定義，然後返回出去（有人說不過在函式內部定義會增加解析負擔）
• JS通過匿名空間隔開公有私有，將匿名函式內部的函式賦值給window下的屬性暴露出去。閉包的經典用法

元件依賴關係（模組化）

試問，如果我們想增加一個有依賴關係的元件怎麼辦？

• 問題：
  
  • 需手動處理元件間的依賴關係。
  • 載入項太多，破壞頁面的整潔度。
    所以require.js就誕生了。
    

js核心語法據說一個星期就設計出來了，所以語法糖它不甜啊，蘋果味的（面向物件）， 荔枝味的（邏輯層），西紅柿味的（模組化）->js框架，js模組化（require）
require.js就是很好的去模擬包，define(定義模組)，return(暴露模組),require()定義入口

require.js會假定元件模組與main.js在同一個目錄

簡單提一下js模組化規範

• AMD（Asynchronous Module Definition）非同步模組規範
• CommonJS，伺服器端模組規範，Node.js
• UMD通用模組規範，相容了AMD和CommonJS
• CMD是SeaJS 在推廣過程中對模組定義的規範化產出
  
  • CMD推崇依賴就近，AMD推崇依賴前置。
  • 對於依賴的模組AMD是提前執行，CMD是延遲執行。
  • AMD的API預設是一個當多個用，CMD嚴格的區分推崇職責單一。

升級

ES6原生 import export 配合 webpack（留坑）

深入（面試問題）

• js的模組化有哪些方式呢？（立即執行匿名函式、名稱空間、sea.js、require.js、es6的import/export）
• require.js和webpack的打包原理分別是什麼樣的？
• 為什麼require.js採用這種方式而webpack採用那種方式？

自定義事件

跳出原生事件的限制，提高封裝的抽象層級。本質是觀察者模式
簡單回撥存在的問題：
1 只能繫結一個回撥函式 ( 只有一個位置傳參 ,一個引數為回撥函式.)
2 回撥的繫結時間和元件例項化時間耦合在一起.(傳入回撥函式的時機是一致的,沒有靈活性.)
關鍵的問題是 沒有將事件抽象分離出來

連綴語法

發展

Promise優雅的元件化