网页设计和网站建设毕业设计,建e网室内设计网图片,十大导航软件,中国信用网官网查询入口组件化 1. 组件化理解 就是将页面的某一部分独立出来#xff0c;将这一部分的数据层#xff08;M#xff09;、视图层#xff08;V#xff09;和控制层#xff08;C#xff09;用黑盒的形式全部封装到一个组件内#xff0c;暴露出一些开箱即用的函数和属性供外部调用。…
组件化 1. 组件化理解 就是将页面的某一部分独立出来将这一部分的数据层M、视图层V和控制层C用黑盒的形式全部封装到一个组件内暴露出一些开箱即用的函数和属性供外部调用。无论这个组件放到哪里去使用它都具有一样的功能和样式从而实现复用只写一处处处复用这种整体化的思想就是组件化 每个组件都是独立的个体都只负责一块功能。组件之间互相独立通过特定的方式进行沟通。外部完全不用考虑组件的内部实现逻辑。一个好的前端组件必须要把维护性复用性扩展性性能做到极致 2. 组件化与模块化的区别 2.1 从历史发展角度来讲 随着前端开发越来越复杂、对效率要求越来越高由项目级模块化开发进一步提升到通用功能组件化开发模块化是组件化的前提组件化是模块化的演进 2.2 从整体概念来讲
模块化是一种分治的思想述求是解耦一般指的是 JavaScript 模块比如用来格式化时间的模块组件化是模块化思想的实现手段述求是复用包含了 templatestylescriptscript又可以由各种模块组成
2.3 从复用的角度来讲
模块一般是项目范围内按照项目业务内容来划分的比如一个项目划分为子系统、模块、子模块代码分开就是模块位于架构业务框架层横向分块组件是按照一些小功能的通用性和可复用性抽象出来的可以跨项目的是可复用的模块通常位于架构底层被其他层所依赖
2.4 从划分的角度来讲
模块是从代码逻辑的角度进行划分方便代码分层开发保证每个功能模块的职能单一组件是从 UI 界面的角度进行划分前端的组件化方便 UI 组件的重用
3. 为什么要前端组件化
随着前端项目复杂度的急剧增加我们很容易遇到以下这些场景
页面逻辑越来越多代码越写越庞大容易牵一发而动全身同样的逻辑在多个地方重复编写改一个问题要在多个地方进行同样的修改
以上场景带来的问题就是
项目复杂度增加重复性劳动多效率低代码质量差不可控
因此前端组件化可以给我们带来
增加代码的复用性灵活性提高开发效率降低开发成本便于各个开发者之间分工协作、同步开发降低系统各个功能的耦合性提高了功能内部的聚合性降低代码的维护成本
4. 组件的划分 4.1 划分方法 尽可能抽象和解耦。不断抽象出一个跟业务没有关系的模块它是可以继承的这就是组件化设计的思维转换。划分粒度需要根据实际情况权衡太小会提升维护成本太大又不够灵活。目前还没有一套原则和方法论来指导组件的划分我们只能根据前人的经验再结合实际情况来进行组件的划分。关于组件划分的一些建议 组件之间的依赖应该尽可能的少。单个组件代码量最好不要超过1000行。组件划分的依据通常是业务逻辑、功能要考虑各组件之间的关系是否明确以及组件的可复用度。每一个组件都应该有其独特的划分目的有的是为了复用实现有的是为了封装复杂度、清晰业务实现。
我经常的做法是如果看到有多个页面都出现了这个重复元素则抽取成一个组件。还有在开发之中发现结构相似的也可以考虑抽取成一个组件。没有必要在一开始就把所有都抽取成一个个组件。
4.2 组件分类 4.2.1 基础UI组件 这是最小化的组件它们不依赖于其他组件。作为页面中最少的元素而存在比如按钮、下拉菜单、对话框等。其中大部分是对原生 Web 元素的封装例如 、 、 它们以简单的形式存在。 在创建基础组件的过程中要遵循一个基本原则基础组件是独立存在的。它们可以共享配置但是不能相互依赖依赖意味着它不是基础组件。像 antd、iview、element-ui 里提供的基本都是基础 UI 组件。
4.2.2 复合组件 复合组件是在多个基础的 UI 组件上的进一步结合。大部分复合组件包含了一些复杂的组件往往需要花很长的时间才能变成一个可稳定使用的版本。复合组件包含以下几个部分 表格表格往往带有复杂的交互比如固定行、固定列、可编辑、虚拟滚动等。由于其数据量大往往又对性能有很高的要求。图表图表的门槛相对比较高并且种类繁多对于显示、交互的要求也高。富文本编辑器几乎是最复杂的组件其功能需求往往与 Word 进行对比其代码量可能接近 Word 的数量级。
4.2.3 业务组件 业务组件是我们在实现业务功能的过程中抽象出来的组件其作用是在应用中复用业务逻辑。当它们涉及一些更复杂的业务情形时就要考虑是否将这些组件放入组件库中。 通常是根据最小业务状态抽象而出有些业务组件也具有一定的复用性但大多数是一次性组件。特点UI可配置业务逻辑完整。有完整的后台流程数据结构。
5. 组件的设计原则
标准性任何一个组件都应该遵守一套标准可以使得不同区域的开发人员据此标准开发出一套标准统一的组件。单一职责原则一个组件只专注做一件事且把这件事做好。一个功能如果可以拆分成多个功能点那就可以将每个功能点封装成一个组件当然也不是组件的颗粒度越小越好只要将一个组件内的功能逻辑控制在一个可控的范围内即可。开闭原则对扩展开放对修改关闭。属性配置等 API 对外开放组件内部状态对外封闭。追求短小精悍避免太多参数扁平化参数除了数据避免复杂的对象尽量只接收原始类型的值。合理的依赖关系父组件不依赖子组件删除某个子组件不会造成功能异常适用SPOTSingle Point of Truth法则尽量不要重复代码追求无副作用复用与易用避免暴露组件内部实现入口处检查参数的有效性出口处检查返回的正确性稳定抽象原则SAP
组件的抽象程度与其稳定程度成正比一个稳定的组件应该是抽象的逻辑无关的一个不稳定的组件应该是具体的逻辑相关的为降低组件之间的耦合度我们要针对抽象组件编程而不是针对业务实现编程
良好的接口设计API 尽量和已知概念保持一致 模块化 1. 模块化理解 1.1 模块化简介 模块化就是把一个个文件看成一个模块它们之间作用域相互隔离互不干扰。一个模块就是一个功能它们可以被多次复用。另外模块化的设计也体现了分治的思想。什么是分治维基百科 (opens new window)的定义如下 字面上的解释是“分而治之”就是把一个复杂的问题分成两个或更多的相同或相似的子问题直到最后子问题可以简单的直接求解原问题的解即子问题的解的合并。 将一个复杂的程序依据一定的规则(规范)封装成几个块(文件), 并进行组合在一起模块的内部数据与实现是私有的, 只是向外部暴露一些接口(方法)与外部其它模块通信 1.2 模块化进程 全局function模式将不同的功能封装成不同的全局函数
编码: 将不同的功能封装成不同的全局函数问题: 污染全局命名空间, 容易引起命名冲突或数据不安全而且模块成员之间看不出直接关系
function m1(){//...
}
function m2(){//...
}namespace模式简单对象封装
作用: 减少了全局变量解决命名冲突问题: 数据不安全(外部可以直接修改模块内部的数据)
let myModule {data: www.baidu.com,foo() {console.log(foo() ${this.data})},bar() {console.log(bar() ${this.data})}
}
myModule.data other data //能直接修改模块内部的数据
myModule.foo() // foo() other dataIIFE模式匿名函数自调用(闭包)
作用: 数据是私有的, 外部只能通过暴露的方法操作编码: 将数据和行为封装到一个函数内部, 通过给window添加属性来向外暴露接口问题: 如果当前这个模块依赖另一个模块怎么办?
// index.html文件
script typetext/javascript srcmodule.js/script
script typetext/javascriptmyModule.foo()myModule.bar()console.log(myModule.data) //undefined 不能访问模块内部数据myModule.data xxxx //不是修改的模块内部的datamyModule.foo() //没有改变
/script
// module.js文件
(function(window) {let data www.baidu.com//操作数据的函数function foo() {//用于暴露有函数console.log(foo() ${data})}function bar() {//用于暴露有函数console.log(bar() ${data})otherFun() //内部调用}function otherFun() {//内部私有的函数console.log(otherFun())}//暴露行为window.myModule { foo, bar } //ES6写法
})(window)IIFE模式增强引入依赖
// module.js文件
(function(window, $) {let data www.baidu.com//操作数据的函数function foo() {//用于暴露有函数console.log(foo() ${data})$(body).css(background, red)}function bar() {//用于暴露有函数console.log(bar() ${data})otherFun() //内部调用}function otherFun() {//内部私有的函数console.log(otherFun())}//暴露行为window.myModule { foo, bar }
})(window, jQuery)
// index.html文件!-- 引入的js必须有一定顺序 --script typetext/javascript srcjquery-1.10.1.js/scriptscript typetext/javascript srcmodule.js/scriptscript typetext/javascriptmyModule.foo()/script通过jquery方法将页面的背景颜色改成红色所以必须先引入jQuery库就把这个库当作参数传入。这样做除了保证模块的独立性还使得模块之间的依赖关系变得明显
1.3 模块化优点
避免命名冲突(减少命名空间污染)更好的分离, 按需加载更高复用性高可维护性
1.4 引入多个 script 的问题
请求过多首先我们要依赖多个模块那样就会发送多个请求导致请求过多依赖模糊我们不知道他们的具体依赖关系是什么也就是说很容易因为不了解他们之间的依赖关系导致加载先后顺序出错难以维护以上两种原因就导致了很难维护很可能出现牵一发而动全身的情况导致项目出现严重的问题。 模块化固然有多个好处然而一个页面需要引入多个js文件就会出现以上这些问题。而这些问题可以通过模块化规范来解决
2. 服务端模块化 2.1 Nodejs和CommonJS的关系
Nodejs的模块化能一种成熟的姿态出现离不开CommonJS的规范的影响在服务器端CommonJS能以一种寻常的姿态写进各个公司的项目代码中离不开Node的优异表现Node并非完全按照规范实现针对模块规范进行了一定的取舍同时也增加了少许自身特性
2.2 CommonJS规范简介 CommonJS对模块的定义非常简单主要分为模块引用模块定义和模块标识3部分 2.2.1 模块引用
var add require(./add.js);
var config require(config.js);
var http require(http);2.2.2 模块定义
module.exports.add function () {...
}
module.exports function () {return ...
}可以在一个文件中引入模块并导出另一个模块
var add require(./add.js);
module.exports.increment function () {return add(val, 1);
}2.2.3 模块标识
模块标识就是require( )函数的参数规范是这样的
必须是字符串可以是以./ …/开头的相对路径可以是绝对路径可以省略后缀名
CommonJS的模块规范定义比较简单意义在于将类聚的方法和变量等限定在私有的作用域中同时支持引入和导出将上下游模块无缝衔接每个模块具有独立的空间它们互不干扰。
2.3 Nodejs的模块化实现 Node模块在实现中并非完全按照CommonJS来进行了取舍增加了一些自身的的特性。 Node中一个文件是一个模块——module 一个模块就是一个Module的实例 // Node中Module构造函数
function Moduleid, parent{this.id id;this.exports {};this.parent parent;if(parent parent.children) {parent.children.push(this);}this.filename null;this.loaded false;this.children [];
}//实例化一个模块var module new Module(filename, parent);其中id 是模块idexports是这个模块要暴露出来的apiparent是父级模块loaded表示这个模块是否加载完成因为CommonJS是运行时加载loaded表示文件是否已经执行完毕返回一个对象。
2.4 Node模块分类 2.4.1 核心模块 就是Node内置的模块比如http path等。在Node的源码的编译时核心模块就一起被编译进了二进制执行文件部分核心模块(内建模块)被直接加载进内存中。 在Node模块的引入过程中一般要经过一下三个步骤 路径分析文件定位编译执行
核心模块会省略文件定位和编译执行这两步并且在路径分析中会优先判断加载速度比一般模块更快。
2.4.2 文件模块 就是外部引入的模块如node_modules里通过npm安装的模块或者我们项目工程里自己写的一个js文件或者json文件。 文件模块引入过程以上三个步骤都要经历
2.5 那么NodeJS require的时候是怎么路径分析文件定位并且编译执行的 2.5.1 路径分析
前面已经说过不论核心模块还是文件模块都需要经历路径分析这一步当我们require一个模块的时候Node是怎么区分是核心模块还是文件模块并且进行查找定位呢Node支持如下几种形式的模块标识符来引入模块
//核心模块
require(http)----------------------------
//文件模块//以.开头的相对路径可以不带扩展名
require(./a.js)//以..开头的相对路径可以不带扩展名
require(../b.js)//以/开始的绝对路径可以不带扩展名
require(/c.js)//外部模块名称
require(express)//外部模块某一个文件
require(codemirror/addon/merge/merge.js);那么对于这个都是字符串的引入方式
Node 会优先去内存中查找匹配核心模块如果匹配成功便不会再继续查找
1比如require http 模块的时候会优先从核心模块里去成功匹配
如果核心模块没有匹配成功便归类为文件模块
2 以.、…和/开头的标识符require都会根据当前文件路径将这个相对路径或者绝对路径转化为真实路径也就是我们平时最常见的一种路径解析3非路径形式的文件模块 如上面的’express’ 和’codemirror/addon/merge/merge.js’这种模块是一种特殊的文件模块一般称为自定义模块。自定义模块的查找最费时因为对于自定义模块有一个模块路径Node会根据这个模块路径依次递归查找。模块路径——Node的模块路径是一个数组模块路径存放在module.paths属性上。我们可以找一个基于npm或者yarn管理项目在根目录下创建一个test.js文件内容为console.log(module.paths),如下
//test.js
console.log(module.paths);然后在根目录下用Node执行
node test.js可以看到模块路径的生成规则如下
当前路文件下的node_modules目录父目录下的node_modules目录父目录的父目录下的node_modules目录沿路径向上逐级递归直到根目录下的node_modules目录
对于自定义文件比如express就会根据模块路径依次递归查找。在查找同时并进行文件定位。
2.5.2 文件定位
扩展名分析
我们在使用require的时候有时候会省略扩展名那么Node怎么定位到具体的文件呢这种情况下Node会依次按照.js、.json、.node的次序一次匹配。.node是C扩展文件编译之后生成的文件若扩展名匹配失败则会将其当成一个包来处理我这里直接理解为npm包
包处理
对于包Node会首先在当前包目录下查找package.jsonCommonJS包规范通过JSON.parse( )解析出包描述对象根据main属性指定的入口文件名进行下一步定位。如果文件缺少扩展名将根据扩展名分析规则定位。若main指定文件名错误或者压根没有package.jsonNode会将包目录下的index当做默认文件名。再依次匹配index.js、index.json、index.node。若以上步骤都没有定位成功将进入下一个模块路径——父目录下的node_modules目录下查找直到查找到根目录下的node_modules若都没有定位到将抛出查找失败的异常。
2.5.3 模块编译
.js文件——通过fs模块同步读取文件后编译执行.node文件——用C/C编写的扩展文件通过dlopen( )方法加载最后编译生成的文件。.json——通过fs模块同步读取文件后用JSON.parse( ) 解析返回结果。其余扩展名文件。它们都是被当做.js文件载入。
每一个编译成功的文件都会将其文件路径作为索引缓存在Module._cache对象上以提高二次引入的性能。这里我们只讲解一下JavaScript模块的编译过程以解答前面所说的CommonJS模块中的require、exports、module变量的来源。我们还知道Node的每个模块中都有___filename、_dirname 这两个变量是怎么来的的呢其实JavaScript模块在编译过程中Node对获取的JavaScript文件内容进行了头部和尾部的包装。在头部添加了function exports require module__filename, __dirname{\n而在尾部添加了\n}); 。因此一个JS模块经过编译之后会被包装成下面的样子
(function(exports, require, module, __filename, __dirname){var express require(express) ;exports.method function (params){...};
});2.6 CommonJS 详解 Node 应用由模块组成采用 CommonJS 模块规范。每个文件就是一个模块有自己的作用域。在一个文件里面定义的变量、函数、类都是私有的对其他文件不可见。在服务器端模块的加载是运行时同步加载的在浏览器端模块需要提前编译打包处理。加载某个模块实质上是加载module.exports属性。就是把另一个js文件的变量或者函数作为一个对象引入了当前js文件。在CommonJS的这种方式下每次require时相当于深拷贝了一份导入模块的文件代码。也就是说执行导入后的某些有副作用的函数并不会改变原模块的变量值。同时因为是同步加载模块服务端的模块都在本地磁盘中所以很适用于服务端。但是对于浏览器环境异步方案显然更加适合 2.6.1 特点
所有代码都运行在模块作用域不会污染全局作用域。模块可以多次加载但是只会在第一次加载时运行一次然后运行结果就被缓存了以后再加载就直接读取缓存结果。要想让模块再次运行必须清除缓存。模块加载的顺序按照其在代码中出现的顺序。
2.6.2 语法
暴露模块module.exports value或exports.xxx value引入模块require(xxx),如果是第三方模块xxx为模块名如果是自定义模块xxx为模块文件路径
此处我们有个疑问CommonJS暴露的模块到底是什么? CommonJS规范规定每个模块内部module变量代表当前模块。这个变量是一个对象它的exports属性即module.exports是对外的接口。加载某个模块其实是加载该模块的module.exports属性。通过require引入的文件自动挂载到了当前文件的children属性中。挂载过后被挂载的文件会随着引入文件执行。同时这个被挂载的文件代码可以理解为引入文件的私有代码与被引入文件无瓜。此时我们可以通过module.children[0].exports拿到被导入文件的各种方法和变量
// example.js
var x 5;
var addX function (value) {return value x;
};
module.exports.x x;
module.exports.addX addX;上面代码通过module.exports输出变量x和函数addX。
var example require(./example.js);//如果参数字符串以“./”开头则表示加载的是一个位于相对路径
console.log(example.x); // 5
console.log(example.addX(1)); // 6require命令用于加载模块文件。require命令的基本功能是读入并执行一个JavaScript文件然后返回该模块的exports对象。如果没有发现指定模块会报错。
3. 客户端模块化 3.1 客户端模块化和服务端模块化有什么区别 服务端加载一个模块直接就从硬盘或者内存中读取了消耗时间可以忽略不计 浏览器需要从服务端下载这个文件所以说如果用 CommonJS 的 require 方式加载模块需要等代码模块下载完毕并运行之后才能得到所需要的API。 3.2 为什么 CommonJS 不适用于前端模块 如果我们在某个代码模块里使用CommonJS的方法require了一个模块而这个模块需要通过http请求从服务器去取如果网速很慢而CommonJS又是同步的所以将阻塞后面代码的执行从而阻塞浏览器渲染页面使得页面出现假死状态。 因此后面AMD规范随着RequireJS的推广被提出异步模块加载不阻塞后面代码执行的模块引入方式就是解决了前端模块异步模块加载的问题。 3.3 AMD(Asynchronous Module Definition) RequireJS CommonJS规范加载模块是同步的也就是说只有加载完成才能执行后面的操作。AMD规范则是非同步加载模块允许指定回调函数。由于Node.js主要用于服务器编程模块文件一般都已经存在于本地硬盘所以加载起来比较快不用考虑非同步加载的方式所以CommonJS规范比较适用。但是如果是浏览器环境要从服务器端加载模块这时就必须采用非同步模式因此浏览器端一般采用AMD规范。此外AMD规范比CommonJS规范在浏览器端实现要来着早。 模块定义
独立模块的定义——不依赖其它模块的模块定义
//独立模块定义
define({method1: function() {}method2: function() {}
}); //或者
define(function(){return {method1: function() {},method2: function() {},}
});非独立模块——依赖其他模块的模块定义
define([math, graph], function(math, graph){...
});模块引用
require([a, b], function(a, b){a.method();b.method();
})3.4 CMD(Common Module Definition) SeaJS CMD——通用模块规范由国内的玉伯提出。SeaJS——CMD的实现其实也可以说CMD是SeaJS在推广过程中对模块定义的规范化产出。与AMD规范的主要区别在于定义模块和依赖引入的部分。AMD需要在声明模块的时候指定所有的依赖通过形参传递依赖到模块内容中 define([dep1, dep2], function(dep1, dep2){return function(){};
})与AMD模块规范相比CMD模块更接近于Node对CommonJS规范的定义
define(factory);在依赖示例部分CMD支持动态引入require、exports和module通过形参传递给模块在需要依赖模块时随时调用require( )引入即可示例如下
define(function(require, exports, module){//依赖模块avar a require(./a);//调用模块a的方法a.method();
})也就是说与AMD相比CMD推崇依赖就近 AMD推崇依赖前置。 3.5 UMD(Universal Module Definition) 通用模块规范
如下是codemirror模块lib/codemirror.js模块的定义方式
(function (global, factory) {typeof exports object typeof module ! undefined ? module.exports factory() // Node , CommonJS: typeof define function define.amd ? define(factory) //AMD CMD: (global.CodeMirror factory()); //模块挂载到全局
}(this, (function () { ...
})可以看说所谓的兼容模式是将几种常见模块定义方式都兼容处理。
3.6 什么是运行时加载
我觉得要从两个点上去理解
CommonJS 和AMD模块都只能在运行时确定模块之间的依赖关系require一个模块的时候模块会先被执行并返回一个对象并且这个对象是整体加载的
//CommonJS 模块
let { basename, dirname, parse } require(path);//等价于
let _path require(path);
let basename _path.basename, dirname _path.dirname, parse _path.parse;上面代码实质是整体加载path模块即加载了path所有方法生成一个对象然后再从这个对象上面读取3个方法。这种加载就称为运行时加载。
3.7 ES6 module 如前面所述CommonJS和AMD都是运行时加载。ES6在语言规格层面上实现了模块功能是编译时加载完全可以取代现有的CommonJS和AMD规范可以成为浏览器和服务器通用的模块解决方案。这里关于ES6模块我们项目里使用非常多所以详细讲解。 3.7.1 ES6模块使用——export
导出一个变量
export var name pengpeng;导出一个函数
export function foo(x, y){}常用导出方式推荐
// person.js
const name dingman;
const age 18;
const addr 卡尔斯特森林;export { firstName, lastName, year };As用法
const s 1;
export {s as t,s as m,
}可以利用as将模块输出多次。
3.7.2 ES6模块使用**——import**
一般用法
import { name, age } from ./person.js;As用法
import { name as personName } from ./person.js;import命令具有提升效果会提升到整个模块的头部首先执行如下也不会报错
getName();import { getName } from person_module;整体模块加载 *
//person.js
export name xixi;
export age 23;//逐一加载
import { age, name } from ./person.js;//整体加载
import * as person from ./person.js;
console.log(person.name);
console.log(person.age);ES6模块使用——export default其实export default在项目里用的非常多一般一个Vue组件或者React组件我们都是使用export default命令需要注意的是使用export default命令时import是不需要加{}的。而不使用export default时import是必须加{}示例如下
//person.js
export function getName() {...
}
//my_module
import {getName} from ./person.js;-----------------对比---------------------//person.js
export default function getName(){...
}
//my_module
import getName from ./person.js;export default其实是导出一个叫做default的变量所以其后面不能跟变量声明语句。
//错误
export default var a 1;值得注意的是我们可以同时使用 export 和 export default
//person.js
export name dingman;
export default function getName(){...
}//my_module
import getName, { name } from ./person.js;前面一直提到CommonJS是运行时加载ES6是编译时加载那么两个有什么本质的区别呢
3.8 ES6 module 与 CommonJS模块加载区别 ES6模块的设计思想是尽量的静态化使得编译时就能确定模块的依赖关系以及输入和输出的变量。所以说ES6是编译时加载不同于CommonJS的运行时加载(实际加载的是一整个对象)ES6模块不是对象而是通过export命令显式指定输出的代码输入时也采用静态命令的形式 //ES6模块
import { basename, dirname, parse } from path;//CommonJS模块
let { basename, dirname, parse } require(path);以上这种写法与CommonJS的模块加载有什么不同
当require path模块时其实 CommonJS会将path模块运行一遍并返回一个对象并将这个对象缓存起来这个对象包含path这个模块的所有API。以后无论多少次加载这个模块都是取这个缓存的值也就是第一次运行的结果除非手动清除。ES6会从path模块只加载3个方法其他不会加载这就是编译时加载。ES6可以在编译时就完成模块加载当ES6遇到import时不会像CommonJS一样去执行模块而是生成一个动态的只读引用当真正需要的时候再到模块里去取值所以ES6模块是动态引用并且不会缓存值。
因为CommonJS模块输出的是值的拷贝所以当模块内值变化时不会影响到输出的值。基于Node做以下尝试
//person.js
var age 18;
module.exports {age: age,addAge: function () {age;}
} //my_module
var person require(./person.js);
console.log(person.age);
person.addAge();
console.log(person.age);//输出结果
18
18可以看到内部age的变化并不会影响person.age的值这是因为person.age的值始终是第一次运行时的结果的拷贝。再看ES6
//person.js
export let age 18;
export function addAge(){age;
}//my_module
import { age, addAge } from ./person.js;
console.log(age);
addAge();
console.log(age);//输出结果
18
19可以看到值被修改了进一步证明了 ES6 的模块化只是对模块文件的引用
3.9 总结
CommonJS规范主要用于服务端编程加载模块是同步的这并不适合在浏览器环境因为同步意味着阻塞加载浏览器资源是异步加载的因此有了AMD CMD解决方案。AMD规范在浏览器环境中异步加载模块而且可以并行加载多个模块。不过AMD规范开发成本高代码的阅读和书写比较困难模块定义方式的语义不顺畅。CMD规范与AMD规范很相似都用于浏览器编程依赖就近延迟执行可以很容易在Node.js中运行。不过依赖SPM 打包模块的加载逻辑偏重ES6 在语言标准的层面上实现了模块功能而且实现得相当简单完全可以取代 CommonJS 和 AMD 规范成为浏览器和服务器通用的模块解决方案。
规范化 规范化的最根本目的就是为了保证团队成员的一致性从而减少沟通成本提高开发效率。我以前就经历过因为规范不标准造成产品与开发理解有偏差、开发各写各的代码导致各种 BUG 不断最后项目延期的事。所以说为了提高开发效率减少加班请一定要统一规范 自动化 前端自动化是指前端代码的自动化构建、打包、测试及部署等流程。 持续集成Continuous IntegrationCI持续部署Continuous DeploymentCD 前端自动化通常与CI/CD流程相结合。 自动化的意义
减少人为失误提高软件质量效率迭代便捷部署快速交付便于管理
自动化的实施
通过构建工具快速完成构建、打包采取自动化测试采取自动化部署 前端监控 性能优化 重构
