044-毕业论文

[fanjiner]

对于前端组件化的思考：
在最开始开发的时候我想大家都经历过原生js或者jquery。
使用一个 datapicker 的 jquery 的插件，所需要的步奏：

1. 引入插件 js
2. 引入插件所需的 css（如果有）
3. copy 组件的所需的 html 片段
4. 添加代码触发组件启动
   现阶段的“ 组件” 基本上只能达到是某个功能单元上的集合。他的资源都是松散地分散在三种资源文件中，而且组件作用域暴露在全局作用域下，缺乏内聚性很容易就会跟其他组件产生冲突，如最简单的 css 命名冲突。对于这种“ 组件”，还不如上面的页面结构模块化。
   于是 W3C制定了一个 WebComponents 标准，为组件化的未来指引了明路。
   1. 模板能力
   模板这东西大家最熟悉不过了，前些年见的较多的模板性能大战 artTemplate，juicer，tmpl，underscoretemplate 等等。而现在又有 mustachejs 无逻辑模板引擎等新入选手。可是大家有没有想过，这么基础的能力，原生 HTML5 是不支持的（T_T）。
   而今天 WebComponent 将要提供原生的模板能力
   template 标签内定义了 datapcikerTmpl 的模板，需要使用的时候就要 innerHTML= document.querySelector('#datapcikerTmpl').content；可以看出这个原生的模板够原始，模板占位符等功能都没有，对于动态数据渲染模板只能自力更新。
    
5. ShadowDom 封装组件独立的内部结构
   ShadowDom 可以理解为一份有独立作用域的 html 片段。这些 html 片段的 CSS 环境和主文档隔离的，各自保持内部的独立性。也正是 ShadowDom 的独立特性，使得组件化成为了可能。
   在具体 dom 节点上使用 createShadowRoot 方法即可生成其 ShadowDom。就像在整份 Html 的屋子里面，新建了一个 shadow 的房间。房间外的人都不知道房间内有什么，保持 shadowDom 的独立性。
    
6. 自定义原生标签
   初次接触 Angularjs 的 directive 指令功能，设定好组件的逻辑后，一个 就能引入整个组件。如此狂炫酷炸碉堡天的功能，实在令人拍手称快，跃地三尺。
   Object.create 方式继承 HTMLElement.prototype，得到一个新的 prototype。当解析器发现我们在文档中标记它将检查是否一个名为 createdCallback 的方法。如果找到这个方法它将立即运行它，所以我们把克隆模板的内容来创建的 ShadowDom。
   最后，registerElement 的方法传递我们的 prototype 来注册自定义标签。
    4. imports 解决组件间的依赖
   WebCompoents 的四部分功能：
   1 . 定义组件的 HTML 模板能力
7. Shadow Dom 封装组件的内部结构，并且保持其独立性
8. Custom Element 对外提供组件的标签，实现自定义标签
9. import 解决组件结合和依赖加载
   组件化
10. 为什么要组件化开发
有时候页面代码量太大，逻辑太多或者同一个功能组件在许多页面均有使用，维护起来相当复杂，这个时候，就需要组件化开发来进行功能拆分、组件封装，已达到组件通用性，增强代码可读性，维护成本也能大大降低


11. 件化开发的优点

    很大程度上降低系统各个功能的耦合性，并且提高了功能内部的聚合性。这对前端工程化及降低代码的维护来说，是有很大的好处的，耦合性的降低，提高了系统的伸展性，降低了开发的复杂度，提升开发效率，降低开发成本1. 前端组件化的原则
• 专一
一个组件只专注做一件事，且把这件事做好。

• 可配置性
一个组件，要明确它的输入和输出分别是什么，要做可配置性，最基本的方式是通过属性向组件传递配置的值，而在组件初始化的声明周期内，通过读取属性的值做出对应的显示修改。还有一些方法，通过调用组件暴露出来的函数，向函数传递有效的值；修改全局 CSS样式；向组件传递特定事件，并在组件内监听该事件来执行函数等。

• 标准性
任何一个组件都应该遵守一套标准，可以使得不同区域的开发人员据此标准开发出一套标准统一的组件。

• 复用性
任何一个组件应该都是一个可以独立的个体，可以使其应用在不同的场景中。

• 可维护性
任何一个组件应该都具有一套自己的完整的稳定的功能，仅包含自身的，与其它组件无关的逻辑，使其更加的容易理解，使其更加的容易理解，同时大大减少发生bug的几率。