① CSS入UI
② CSS作为组件的一个节点而存在，并且会被“格式化”，即选择器带id前缀，形成的组件如图所示：
这样做基本可以规避css污染的问题，解决绝大多数问题，但是更优的方案总是存在，比如web components中的shadow dom！
javascript的组件基本是不可重用的，几个核心原因是：
① 组件实例与实例之间的html、css、Javascript很容易互相污染（id污染、class污染、js变量污染......）
② 一个组件依赖于HTML、CSS、Javascript，而三者之间是分离的，而组件内部控制于js，更改后外部可能出问题
通过昨天的处理，我们将一个组件所用到的全部合到了一起，却又分离成了三个文件：
这种处理一方面透露着解耦的思想，另一方面体现着解依赖的想法，在这个基础上想引入shadow dom技术，变得非常轻易。
shadow dom是一种浏览器行为，他允许在document文档中渲染时插入一个独立的dom子树，但这个dom树与主dom树完全分离的，不会互相影响。
从一张图来看：
shadow dom事实上也是一个文档碎片，我们甚至可以将之作为jQuery包装对象处理：
存在在shadow dom中的元素是不可被选择器找到的，比如这种做法会徒劳无功：
另一个比较重要的差别是，外部为组件定义的事件，比如click事件的e.target便只能是组件div了，也就是这个组件事实上只有一层，一个标签，内部的结构不会被暴露！
原来我们的组件是这样的结构：
框架会主动创建一个包裹层，包裹层内才是组件dom，经过昨天的处理，组件变成了这样：
如果这里我们使用shadow dom技术的话，整个结构会变成这样：
组件自动创建的dom包裹层，里面神马都没有了，因为事件代理是进不去的，所以开启shadow dom方式的组件需要将事件绑定至shadow节点
当然，并不是所有浏览器都支持shadow dom技术，当此之时，也不是所有的shadow dom都合适；所以UI基类需要做一个开关，最大限度的避免生产风险，而又能引入新的技术
基类会多出几个属性处理，shadow逻辑，然后在创建UI dom节点时候需要进行特殊处理
在开启shadow dom功能的情况下，便会为根节点创建shadow root，将style节点与html节点装载进去，这个时候UI结构基本出来了，事件便绑定至shadow root即可，这里是全部代码：
View Code
基类代码改动结束，一旦开启shadow dom开关，每个组件便会走shadow逻辑，否则走原逻辑：
关闭接口的话，又变成了这个样子了：
web components的提出，旨在解决UI重用的问题、解决相同功能接口各异的问题，大规模的用于生产似乎不太接地气，但是shadow dom技术对于webapp却是个好东西。
上文还只是在UI层面上应用shadow dom技术，webapp中每个view页面片如果可以应用shadow dom技术的话，各个View将不必考虑id重复污染、css样式污染、javascript变量污染，并且效率还比原来高多了，因为对于页面来说，他就仅仅是一个标签而已，如此一来，大规模的webapp的网站可能真的会到来了！
博主正在学习web components技术，并且尝试将之用于项目，文中有误或者有不妥的地方请您提出
本文转自叶小钗博客园博客，原文链接：http://www.cnblogs.com/yexiaochai/p/4167554.html，如需转载请自行联系原作者