WEB组件化思想

JS不同层的职责和API

1. 浏览器低层分层大概也可以分为DOM / BOM / STYLE 样式 /Canvas 2D / WebGL / SVG

浏览器底层面临的一些问题

1. JS核心语法层面薄弱
2. JS原生API不好用 （ajax , cookie ,）
3. 浏览器兼容问题 （IE9微软用了自己一套的东西，搞事情？）

对过时浏览器的兼容性问题是沉重的知识包袱， 关键是这种知识没有延续性，会影响你学习和使用新技术

框架core

Prototype,YUI,Dojo,jquery

框架组件

封装浏览器原生API，抽象成组件

input text checkbox radio select

没有日历选择器，富文本编辑器，Excuse me?

• 框架组件->高度重用
  
  • 独立组件底层（原生js层，不用依赖框架）
  • 定制组件（小白->大牛写）
  • 框架通用组件（大牛写）

详细演变：https://www.zhihu.com/question/29735633

组件定义和加载

js部分
var H5ComponentBase = function (name,cfg ) {属性+方法}

css部分
啪啪啪啪啪啪（一阵敲键盘声音）

然后引入文件，实例化对象

var cfg = {参数}
var h5 = new H5ComponentBase('bob',cfg);
            $('.iphone').append(h5);

多个组件打架（变量冲突）

解决方法：

• css通过加前缀形成命名空间（tab_view）
• JS在函数内部定义，然后返回出去（有人说不过在函数内部定义会增加解析负担）
• JS通过匿名空间隔开公有私有，将匿名函数内部的函数赋值给window下的属性暴露出去。闭包的经典用法

组件依赖关系（模块化）

试问，如果我们想增加一个有依赖关系的组件怎么办？

• 
  
• 问题：
  
  • 需手动处理组件间的依赖关系。
  • 加载项太多，破坏页面的整洁度。
    所以require.js就诞生了。
    

js核心语法据说一个星期就设计出来了，所以语法糖它不甜啊，苹果味的（面向对象）， 荔枝味的（逻辑层），西红柿味的（模块化）->js框架，js模块化（require）
require.js就是很好的去模拟包，define(定义模块)，return(暴露模块),require()定义入口
require.js会假定组件模块与main.js在同一个目录

简单提一下js模块化规范

• AMD（Asynchronous Module Definition）异步模块规范
• CommonJS，服务器端模块规范，Node.js
• UMD通用模块规范，兼容了AMD和CommonJS
• CMD是SeaJS 在推广过程中对模块定义的规范化产出
  
  • CMD推崇依赖就近，AMD推崇依赖前置。
  • 对于依赖的模块AMD是提前执行，CMD是延迟执行。
  • AMD的API默认是一个当多个用，CMD严格的区分推崇职责单一。

升级

ES6原生 import export 配合 webpack（留坑）

深入（面试问题）

• js的模块化有哪些方式呢？（立即执行匿名函数、命名空间、sea.js、require.js、es6的import/export）
• require.js和webpack的打包原理分别是什么样的？
• 为什么require.js采用这种方式而webpack采用那种方式？

自定义事件

跳出原生事件的限制，提高封装的抽象层级。本质是观察者模式
简单回调存在的问题：
1 只能绑定一个回调函数 ( 只有一个位置传参 ,一个参数为回调函数.)
2 回调的绑定时间和组件实例化时间耦合在一起.(传入回调函数的时机是一致的,没有灵活性.)
关键的问题是 没有将事件抽象分离出来

连缀语法

发展

Promise优雅的组件化