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语法扩展、自动兼容处理等
扫码二维码关注个人公众号: