IOING在開發SPA大型應用時有哪些必要的技術條件？

前言

以前公衆號《前端早讀課》推了個人文章（在這裏表示感謝），不少同窗有在底下留言，問我 Ionic 和 IOING 是什麼關係？從名字來看二者的開頭雖然都是 IO 打頭但其實二者毫無關係，一丁點兒都沒有。

IOING 是一款高性能的前端開發引擎。它爲建立一個大型應用提供一整套的完備方案，如頁面模塊化拆分、層級路由控制、可編程CSS、熱拔插組件、雙向數據綁定、DOM語法擴展、自動兼容處理等

IOING 的歷史大概有5年之久了，一直做爲私人項目使用，使用文檔也在近期發佈的。我在這以前將其中的兩個功能點做爲推廣試水，因而收到了不少朋友的郵件和微信表示對該項目很感興趣，因此我想 IOING 在用戶接受程度上仍是蠻高的，因而有了這篇文章來討論 IOING 的獨特之處

打造 SPA 應用應該具有的技術條件

條件一：自有滾動

做爲一款應用應該能和 WEB 體驗有明顯區分，首先主要體如今佈局上，合適的佈局至少讓應用從外觀上看起來就更像是個 App，好比你的 WebApp 應當有 header 和 footer，固然這些技術實現上都比較簡單，稍微複雜的例子是多重滾動嵌套視圖，好比下面的效果

（示例：1-1）

這個例子中的有三個可滾動區域，一個最外層的父級滾動，另外兩個是 tab 頁面的子滾動，且子滾動和父級滾動有着事件的交互傳遞

（示例：1-2）

對於 1-2 示例就要更復雜一些了，首先最外層是頁面滾動，組件父級是一個橫向滑動，左右滑動時切換不一樣選項卡，鼠標上下滑動到底也須要切換卡片，每一個卡片內部還有不少的子滾動

這麼多層嵌套的滾動效果對於前端開發來講無疑是一個很大的工做量，而咱們將其抽象來看的話咱們須要什麼呢？咱們須要一個強大的滾動 API，而這一點需求瀏覽器偏偏沒有提供。咱們目可用的滾動除了可憐的 body 滾動外還有部分可使用 overflow-scrolling:touch 來支持區域滾動的方法，body 滾動只侷限在窗口，而且滾動條會覆蓋 header 和 footer 很是醜陋，在不一樣設備上滾動慣性也不一致，效果很是很差，而 overflow-scrolling 除了有兼容問題外自身 API 也基本沒有，因此咱們只能放棄以上方案，本身造輪子吧。

關於 js滾動庫中也存在着不少問題，iscroll.js 就是一個知名的滾動庫，我先來簡單說一下關於 js滾動庫的缺點

1. 不當的 CSS 佈局可致使其性能急劇下滑
2. 沒法經過設置 0s 動畫來中止當前 CSS3 動畫的兼容問題
3. 內容更新時不能及時更新滾動對象
4. 大數據列表時可致使 GPU 內存不足，從而嚴重卡頓
5. Android 中觸摸反饋動畫掉幀嚴重

嗯、好像問題很多，要解決這寫問題要從不少方面思考，這裏就不展開詳解只簡單說一下這裏關聯到的 IOING 中的另外一個神奇：DOM 引擎，經過該引擎能自動化處理不少問題，好比像下面這樣建立一個滾動控件

<scroll fullscreen x y>
    <scrolling>
        內容...
    </scrolling>
</scroll>

這樣就完成了一個全屏的橫豎向滾動控件

條件二：模塊轉場與模塊控制和沙盒機制

做爲一個 App，功能模塊間切換必定是要保持狀態的，即每一個模塊的瀏覽痕跡不能銷燬，好比你在 A列表頁進行瀏覽，這時看到一條吸引你的內容點進去 B內容頁，點擊的一瞬間會經過一個動畫將 A列表頁和 B內容頁同時進行動畫轉場，此時兩個模塊就必須都有自有滾動控件了，當返回時 A列表頁應停留在歷史位置。滾動控件的問題在上面有解決方案了，除了歷史位置問題外，想要完成模塊切換還有更多的問題：

1. 載入模塊愈來愈多，你們都堆放在同一個 DOM Tree下，必然會帶來高耦合，同時一顆龐大的 DOM Tree 也致使了嚴重的性能問題。這些功能模塊的CSS、Js、html 被放置在一塊兒時，將很難避免相互影響，形成難以測試的 bug。
2. 高耦合下模塊在卸載時難以卸載乾淨，餘留的全局變量或殭屍事件將一直影響着後續操做
3. 直接訪問任何一個路由頁面時應當能在返回時返回到程序主屏幕
4. 歷史記錄應按照應用層級返回，好比訪問歷史：商品列表頁-詳情頁-訂單頁-支付頁-支付完成頁，此時若是用戶完成交易後點擊返回是不該該再進入訂單頁和支付頁的，而應該直接進去詳情頁或列表頁，因此在路由控制上必須有解決方案
5. 模塊與模塊間不該可以直接操做，應該有通訊規範
6. 模塊被緩存時應有生命週期管理，以保證模塊正常更新
7. 模塊數據資源也應有生命週期管理，以保證數據的正常更新
8. 模塊的更新操做應保證舊數據與新數據更替間不出現白屏現象
9. 模塊應該有本身的資源管理，數據管理，事件管理，配置管理等方案
10. 模塊智能預載方案
11. 模塊類型方案：嵌入式模塊，系統模塊，獨立模塊
12. 不一樣類型模塊的轉場，並提供動畫接口
13. 保證動畫性能，須要創建動畫隊列，對全部動畫操做進行統一封裝

以上部分都是當你決定要作模塊頁面轉場時不得不考慮的問題，除了這些主要問題外還有不少細節問題須要考慮，好比動畫前指定加載模塊如何迅速渲染完畢等等。
模塊中可對模塊配置自定義函數動畫，也可使用內置默認動畫，向下面這樣的效果

animation:'fade'

animation:'flip'

animation:'zoom'

animation:'slide'

對於模塊管理方面 IOING 設計了不少方案，好比資源管理方面IOING 經過一個配置文件進行統一管理

(模塊配置文件)
在模塊配置文件中描述了該模塊的資源庫、類型、事件、級別、運行方式、以及轉場動畫等，其中sandbox項能讓模塊在沙盒下運行，即保證模塊擁有本身的獨立運行空間

條件三：可拔插組件及組件通訊

其實在 webComponent 技術規範以前咱們就已經在使用 web 組件了，最多見的 web 組件就是 input，那咱們怎麼才能實現一個想 input 這樣的組件呢？
瀏覽器須要支持以下特性：

1. Custom elements
2. Template
3. Shadow DOM
4. <script type="module">
5. HTML imports

對於這些特性都是須要瀏覽器自身實現的，而當你不肯定你的受衆設備是否知足這些條件時你須要找到完美降級方案，好比在 IOING 中使用 <shadow>標籤 能夠建立一個新的 ShadowDom，以保證新元素不會增長外部高耦合

(示例 3-1)

該示例是一個組件在瀏覽器中所呈現的結構

當你在一個或多個模塊中引用了多個相同組件時就會涉及一個問題：組件通訊。
好比你每一個組件副本都須要獲取一段數據，那麼若是每一個組件都各自進行獲取數據源顯然是不正確的，那麼此時就須要一個總控來進行作數據管理
再來一個例子你有一個開關的組件在多個模塊中都被引用到，此時當你關閉了其中一個開關組件，那該數據應同步到全部其餘開關組件中

條件四：可編程CSS及物理像素

作過手機端 h5 開發的同窗都應該有體會，尤爲是在 ios 上，1px 老是比預期的要粗，由於這個問題很多前端也被視覺同窗吐槽過。
那爲何會出現這樣的問題呢？這是由於如今的手機分辨率愈來愈高，若是把 iphone 的 1px 像素點和普通 pc顯示器的 1像素點放在一塊兒對比，你會發現 iphone 的1px 要小不少，這個小於標準像素的倍數就是咱們常說的devicePixelRatio，既然像素變小了那應該在 iphone 上看同一個頁面應該更小纔對呀，也正是由於這樣問題才催生了viewport。
viewport 的做用就像是等比拉伸一張圖那樣，最終圖像中 1px 的細節很明顯受到影響，失去髮髻線效果。所以咱們首先要作的就是把viewport特性幹掉，而幹掉後咱們還須要一個新單位來解決適配問題，因而就有了新單位dp dp = density px = devicePixelRatio * px
固然有了dp還不夠，咱們還須要結合vm，vh，vw等來作更多的適配工做，可是並非全部設備都支持這些單位，因此咱們還須要一個 CSS引擎來處理這些問題，好比 calc計算

div {
    width: calc(50vw - 20dp + 1px)
}

多個單位合併計算的場景在 App設計過程當中很常見，若是不能兼容掉將會很是影響開發效率
再來一個例子，在你的 App中 header的高度等於 60dp，而且它還有 1px 的邊線，所以它在 DPI爲 3 的設備下應該等於 181px，在DPI 爲 2的設備下等於 121dp，在另外一個模塊的 CSS中咱們但願知道 header 的高度時一樣應該有一種機制讓模塊間共享數據，在 IOING 中就像下面這樣

/*主模塊 CSS文件*/
@global {
    header-height: calc(60dp + 1px);
}

/*A模塊 CSS文件*/
div {
    top: [header-height];
}

有時候光知足 CSS 內變量代換還不夠，咱們還要支持 CSS 中引入模塊數據源，就像模版語法那樣，CSS也應該有本身的邏輯語法

@if(device.os.ios) {
    header {
        backdrop-filter: blur(20dp);
    }
}

更多用法關注這裏http://ioing.com/#docs-css-scope/

---

華麗分割線

---

QA

IOING 是什麼？

IOING 是一款高性能的前端開發引擎。它爲建立一個大型應用提供一整套的完備方案，如頁面模塊化拆分、層級路由控制、可編程CSS、熱拔插組件、雙向數據綁定、DOM語法擴展、自動兼容處理等

IOING 項目還須要 SASS、LESS、Stylus 等嗎？

不須要。IOING 是一個純前端引擎，全部服務都是前端運行的結果

IOING 和 React、vue、Angular 的區別在哪裏？

IOING 從容器層解決了不少 web開發難題，目的是爲了提供一套完整的 SPA開發方案，而不是解決某幾方面的問題。

結尾

IOING 的文檔目前還不夠完善，但徹底能夠知足必要的開發。對於文檔的更新工做我往後會持續，也歡迎對 IOING 該興趣的同窗關注個人公衆號或 star我

項目地址：https://github.com/ioing/IOING

公衆號請掃：