JS不同层的职责和API
- 浏览器低层分层大概也可以分为DOM / BOM / STYLE 样式 /Canvas 2D / WebGL / SVG
浏览器底层面临的一些问题
- JS核心语法层面薄弱
- JS原生API不好用 (ajax , cookie ,)
- 浏览器兼容问题 (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优雅的组件化