回顾
经过昨天的优化处理（【前端优化之拆分CSS】前端三剑客的分分合合），我们在UI一块做了几个关键动作：
① CSS入UI
② CSS作为组件的一个节点而存在，并且会被“格式化”，即选择器带id前缀，形成的组件如图所示：
这样做基本可以规避css污染的问题，解决绝大多数问题，但是更优的方案总是存在，比如web components中的shadow dom！
javascript的组件基本是不可重用的，几个核心原因是：
① 组件实例与实例之间的html、css、Javascript很容易互相污染（id污染、class污染、js变量污染......）
② 一个组件依赖于HTML、CSS、Javascript，而三者之间是分离的，而组件内部控制于js，更改后外部可能出问题
通过昨天的处理，我们将一个组件所用到的全部合到了一起，却又分离成了三个文件：
① ui.js
② ui.html
③ ui.css
这种处理一方面透露着解耦的思想，另一方面体现着解依赖的想法，在这个基础上想引入shadow dom技术，变得非常轻易。
什么是shadow dom
shadow dom是一种浏览器行为，他允许在document文档中渲染时插入一个独立的dom子树，但这个dom树与主dom树完全分离的，不会互相影响。
从一张图来看：
shadow dom事实上也是一个文档碎片，我们甚至可以将之作为jQuery包装对象处理：
存在在shadow dom中的元素是不可被选择器找到的，比如这种做法会徒劳无功：
$('沙箱中的一个元素') => []
另一个比较重要的差别是，外部为组件定义的事件，比如click事件的e.target便只能是组件div了，也就是这个组件事实上只有一层，一个标签，内部的结构不会被暴露！
引入框架
原来我们的组件是这样的结构：
1 <div id="ui-view-16" style=""> 2 <div class="cm-num-adjust"> 3 <div class="cm-num-adjust"> 4 <span class="cm-adjust-minus js_num_minus disabled "></span><span class="cm-adjust-view js_cur_num " 5 contenteditable="true">1个</span> <span class="cm-adjust-plus js_num_plus "></span> 6 </div> 7 </div> 8 </div>
框架会主动创建一个包裹层，包裹层内才是组件dom，经过昨天的处理，组件变成了这样：
1 <!--组件生成的包裹层--> 2 <div id="wrapper" > 3 <!--组件格式化后的样式--> 4 <style> 5 #wrapper { ......} 6 </style> 7 8 <!--组件真实的dom结构--> 9 <div></div> 10 <div>
如果这里我们使用shadow dom技术的话，整个结构会变成这样：
1 <div id="wrapper"> 2 #shadow-root 3 <style></style> 4 <div> 5 </div> 6 <div>
组件自动创建的dom包裹层，里面神马都没有了，因为事件代理是进不去的，所以开启shadow dom方式的组件需要将事件绑定至shadow节点
当然，并不是所有浏览器都支持shadow dom技术，当此之时，也不是所有的shadow dom都合适；所以UI基类需要做一个开关，最大限度的避免生产风险，而又能引入新的技术
1 //与模板对应的css文件，默认不存在，需要各个组件复写 2 this.uiStyle = null; 3 4 //保存样式格式化结束的字符串 5 // this.formateStyle = null; 6 7 //保存shadow dom的引用，用于事件代理 8 this.shadowDom = null; 9 this.shadowStyle = null; 10 this.shadowRoot = null; 11 12 //框架统一开关，是否开启shadow dom 13 this.openShadowDom = true; 14 15 // this.openShadowDom = false; 16 17 //不支持创建接口便关闭，也许有其它因素导致，这个后期已接口放出 18 if (!this.wrapper[0].createShadowRoot) { 19 this.openShadowDom = false; 20 }
基类会多出几个属性处理，shadow逻辑，然后在创建UI dom节点时候需要进行特殊处理
1 createRoot: function (html) { 2 3 this.$el = $('<div class="view" style="display: none; " id="' + this.id + '"></div>'); 4 var style = this.getInlineStyle(); 5 6 //如果存在shadow dom接口，并且框架开启了shadow dom 7 if (this.openShadowDom) { 8 //在框架创建的子元素层面创建沙箱 9 this.shadowRoot = $(this.$el[0].createShadowRoot()); 10 11 this.shadowDom = $('<div class="js_shadow_root">' + html + '</div>'); 12 this.shadowStyle = $(style); 13 14 //开启shadow dom情况下，组件需要被包裹起来 15 this.shadowRoot.append(this.shadowStyle); 16 this.shadowRoot.append(this.shadowDom); 17 18 } else { 19 20 this.$el.html(style + html); 21 } 22 },
在开启shadow dom功能的情况下，便会为根节点创建shadow root，将style节点与html节点装载进去，这个时候UI结构基本出来了，事件便绑定至shadow root即可，这里是全部代码：
View Code
基类代码改动结束，一旦开启shadow dom开关，每个组件便会走shadow逻辑，否则走原逻辑：
关闭接口的话，又变成了这个样子了：
引入shadow dom的意义
web components的提出，旨在解决UI重用的问题、解决相同功能接口各异的问题，大规模的用于生产似乎不太接地气，但是shadow dom技术对于webapp却是个好东西。
上文还只是在UI层面上应用shadow dom技术，webapp中每个view页面片如果可以应用shadow dom技术的话，各个View将不必考虑id重复污染、css样式污染、javascript变量污染，并且效率还比原来高多了，因为对于页面来说，他就仅仅是一个标签而已，如此一来，大规模的webapp的网站可能真的会到来了！
demo地址：http://yexiaochai.github.io/cssui/demo/debug.html#num
代码地址：https://github.com/yexiaochai/cssui/tree/gh-pages
博主正在学习web components技术，并且尝试将之用于项目，文中有误或者有不妥的地方请您提出
本文转自叶小钗博客园博客，原文链接：http://www.cnblogs.com/yexiaochai/p/4167554.html，如需转载请自行联系原作者
