IOING 在你的代碼和瀏覽器之間架設了一箇中間解釋層,該解釋層提供了一套新的語法來填補瀏覽器所不具有的能力。前端
開發一個 SPA 應用的痛點是不一樣模塊頁面的狀態保存,當從一個頁面跳轉到另外一個頁面的時候窗口的全部狀態都將被清空重載,歷史頁面與當前頁面將不產生任何聯繫,這個過程是一個拆毀重建的過程,若是你要回到歷史一樣只能再次拆毀重建,而且在這個過程當中不可避免的出現加載期的窗口白屏,顯然這樣的醜陋效果不符合一個高貴 App 的設定,但正因這種方式先後頁面不共存的簡單特性也使得開發邏輯變得簡單,開發者只需考慮單個頁面的邏輯便可,而每一次新頁面的加載都能將以前頁面進行徹底釋放,徹底不須要擔憂高耦合和內存沒法徹底釋放的問題,這也算是傳統技術的優勢,雖然簡單粗暴,可是它很管用。那到底有沒有一箭雙鵰的辦法呢?ios
和 SPA 應用不一樣的是多頁面應用每每相對要變得簡單,頁面與頁面之間不須要有複雜的數據交換,也無需保存頁面歷史狀態,所以使用傳統技術最適合不過了。git
而 SPA 應用則要協調頁面間的關係,它的每個模塊均可能是聯動的,並且須要保持窗口的數據狀態,於是催生了另外一個技術的流行,即經過使用 Ajax 和模版將新模塊內容載入到當前頁面,但這也致使新載入模塊的腳本和 DOM 樹內容在主文檔下不斷堆積,且在不須要時也沒法將其很好移除和釋放(好比 setTimeout 等殭屍事件)。另外一種狀況是一旦其中一個模塊發生錯誤將頗有可能致使整個 SPA 應用崩潰。github
除了高耦合問題外,Ajax 每次載入大量的 DOM 結構到主 DOM Tree 下時都將可能會致使這個龐大的 DOM Tree 進行 reflow(迴流) 和 repaint(重繪),從而影響總體運行效率web
基於上述分析,咱們要獲得一個穩定的 SPA 應用時必須改造瀏覽器使其支持如下特性:算法
只有具有了這些特性時才能保證一個大型 WEB 應用的穩定運行,那麼對於上述問題 IOING 是怎麼處理的呢?編程
首先爲了保證模塊的代碼錯誤不至於影響整個應用的運行,咱們須要保證除引擎外的全部不可控腳本都不能運行在主 window 下,而模塊腳本自須要運行在單獨的沙盒中。segmentfault
沙盒(Sandbox)簡單來說就是: <iframe src="_blank" sandbox="..."></iframe>
無需解釋你們也就都懂了,可是不少人在看到 iframe 時就開始各類擔憂起來,聯想起各類文章對 iframe 的負面描述。這裏須要解釋一下,iframe 直接做爲嵌入網頁使用時確實會佔用當前頁面鏈接池,但其在引擎中其主要目的是做爲沙盒使用而並非爲了嵌入網頁使用的,當引擎將編譯好內容時會先主動建立一個空 iframe,而後直接將編譯內容直接丟入其中,注意 iframe 的 src="_blank",這是一個空頁面,該狀況下 iframe 並不會共享主窗口鏈接池。瀏覽器
咱們設想一下這樣一個場景:你在瀏覽器打開多個窗口分別載入不一樣的模塊頁面,而後在你須要打開其餘頁面時能經過自定義動畫使瀏覽器窗口進行動畫過渡將頁面展現,當你返回時也能經過反向動畫再將以前窗口內容過渡回來,若是瀏覽器支持這些或許 webApp 看起來將更酷,但現實是瀏覽器並無這樣的操做?♂️。app
而這個設想能夠經過沙盒來實現,在沙盒中的頁面就像新開一個瀏覽器窗口那樣,可以很好的隔離模塊的 DOM 元素和變量,也能保存頁面狀態,並能經過動畫控制其轉場。
沙盒雖然很穩妥,但其過於獨立,這致使模塊內元素不能突破沙盒限制顯示在模塊外區域,好比說一些複合型模塊(即嵌入主模塊中的模塊,沙盒通常適用與獨立的全屏模塊),當你有這個需求時沙盒特性則不能知足你,此時你應該支持另外一種模塊運行方式:shadowbox 應運而生。
使用 shadowbox 配置的模塊,其模塊內容將以一顆新 DOM Tree 插入到主 DOM Tree 中(即 shadowdom 方式),這顆新 DOM Tree 中的 CSS樣式 和 元素id 將不會和外部元素耦合,而此時模塊的 js 文件則依舊在其沙盒中運行。(若運行瀏覽器不支持該特性時應自動降級處理)
固然只有一個沙盒模型是遠遠不夠的,好比組件一樣須要一套合理運做機制。以後「兩分鐘瞭解IOING」將會繼續推出如下話題:
更多敬請期待...
IOING在開發SPA大型應用時有哪些必要的技術條件?
如何用 js 獲取虛擬鍵盤高度?(適用全部平臺)
讓 CSS 完成背景圖加載完畢後顯示 之 解析 IOING 的 onload url 原理
IOING 是一款高性能的前端開發引擎。它爲建立一個大型應用提供一整套的完備方案,如頁面模塊化拆分、層級路由控制、可編程CSS、熱拔插組件、雙向數據綁定、DOM語法擴展、自動兼容處理等
掃碼二維碼關注個人公衆號: