写在前面
最近致力于研究 Web components（以下简称WC），并且也初有成效的拿到了一定的结果，但今天想回过头来重新审视一下 WC。
WC 到底是什么？
简单的讲，Web Component 就是把组件封装成 html 标签的形式，并且在使用时不需要写额外的 js 代码。
组件是前端的发展方向，抛开周边技术生态，单纯看 React 和 Vue 都是组件框架。因此，WC 可以视为原生标签的拓展/延伸，说到底，它依旧是一个标签！
类似 标签，相比于原生标签，它多了更为丰富的样式和可操作属性。
谷歌公司由于掌握了 Chrome 浏览器，一直在推动浏览器的原生组件，即 Web Components API。
相比第三方框架，原生组件简单直接，符合直觉，不用加载任何外部模块，代码量小。貌似一切完美，似乎大有可以用来替换React、Vue之类的趋势。
目前存在的缺陷
与其它 web 框架一起使用存在一些小问题，会给开发体验上造成一些困扰。
1、组件内部事件的回调
比如，一个弹窗组件（
class myDialog extends HTMLElement {
// ...
connectedCallback() {
const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.innerHTML = `
弹窗内容
`;
shadowRoot.querySelector('#okBtn').addEventListener('click', () => {
// 组件内部定义事件
this.dispatchEvent(new CustomEvent('okBtnFn'));
});
}
}
customElements.define('my-dialog', myDialog);
现在方案是 custom element 内部自定义事件 new CustomEvent()，外部用 addEventListener监听。这样的写法是很丑陋的，仿佛又回到了原生 JS 写应用的时代。
2、组件样式覆盖
对于开发者来说，难免会遇到需要调整组件内部样式的时候。无论你是使用antd、vant还是使用其它组件库，但 WC 的 CSS 防污染机制导致你很难修改内部样式。这需要你付出一些代价来变相的修改内部样式
3、组件内部资源相对路径问题
就目前来说，任何直接基于 Custom Element v1, Template 和 HTML Import 的组件都无法做到完全资源独立 —— 在不知道使用方环境且不给使用方增加额外限制的情况下使用内部封装的任何资源文件。比如如果你有一个自定义 icon 组件：
class MyIcon extends HTMLElement {
static get observedAttributes() { return ['name','size','color'] }
constructor() {
super();
const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.innerHTML = `
}
attributeChangedCallback (name, oldValue, newValue) {
if( name == 'name' && this.shadowRoot){
// 如果使用的项目中，根目录没有 icon.svg 文件，那就 gg
this.use.setAttributeNS('http://www.w3.org/1999/xlink', 'xlink:href', `./icon.svg#icon-${newValue}`);
}
}
}
customElements.define('my-icon', MyIcon);
如果使用的项目中，根目录没有 icon.svg 文件，那就 gg。如果你在这里使用 cdn 路径，就会出现跨域问题。
4、form表单类组件 value 获取问题
Shadow DOM 中包含有 、