前端模块化(一)---来源、历史、CJS、Export、Require、模块加载过程

看月亮的方源
157 阅读11分钟

1. Node.js是什么

  1. 官方对Node.js的定义：
  • Node.js是一个基于V8 JavaScript引擎的JavaScript运行时环境。

image.png

  1. 也就是说Node.js基于V8引擎来执行JavaScript的代码，但是不仅仅只有V8引擎：
  • 我们知道V8可以嵌入到任何C ++应用程序中，无论是Chrome还是Node.js，事实上都是嵌入了V8引擎来执行 JavaScript代码；
  • 但是在Chrome浏览器中，还需要解析、渲染HTML、 CSS等相关渲染引擎，另外还需要提供支持浏览器操作的API、浏览器自己的事件循环等；
  • 另外，在Node.js中我们也需要进行一些额外的操作，比如文件系统读/写、网络IO、加密、压缩解压文件等操作；

2. 浏览器和Node.js架构区别

  1. 我们可以简单理解规划出Node.js和浏览器的差异：

image.png 2. 我们来看一个单独的Node.js的架构图：

  • 我们编写的JavaScript代码会经过V8引擎，再通过Node.js的Bindings，将任务放到Libuv的事件循环中；
  • libuv（Unicorn Velociraptor—独角伶盗龙）是使用C语言编写的库；
  • libuv提供了事件循环、文件系统读写、网络IO、线程池等等内容；

image.png

image.png

3. Node中输入

// 1.输出
console.log("hell world!");

// 2.给程序输入内容
const num1 = 200;
const num2 = 300;
console.log(num1 + num2);
console.log(process.argv);

const arg1 = process.argv[2];
const arg2 = process.argv[3];

console.log(arg1, arg2);

image.png

为什么叫argv呢？

  1. 在C/C++程序中的main函数中，实际上可以获取到两个参数：
  • argc：argument counter的缩写，传递参数的个数；
  • argv：argument vector（向量、矢量）的缩写，传入的具体参数。
    • vector翻译过来是矢量的意思，在程序中表示的是一种数据结构。
    • 在C++、Java中都有这种数据结构，是一种数组结构；
    • 在JavaScript中也是一个数组，里面存储一些参数信息

4.Node的REPL

  1. 什么是REPL呢？感觉挺高大上
  • REPL是Read-Eval-Print Loop的简称，翻译为“读取-求值-输出”循环；
  • REPL是一个简单的、交互式的编程环境；

  1. 事实上，我们浏览器的console就可以看成一个REPL。

  2. Node也给我们提供了一个REPL环境，我们可以在其中演练简单的代码。

  3. node的REPL image.png

  4. 浏览器的REPL

image.png

5. 什么是模块化？

  1. 到底什么是模块化、模块化开发呢？
  • 事实上模块化开发最终的目的是将程序划分成一个个小的结构；
  • 这个结构中编写属于自己的逻辑代码，有自己的作用域，定义变量名词时不会影响到其他的结构；
  • 这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用；
  • 也可以通过某种方式，导入另外结构中的变量、函数、对象等；
  1. 上面说提到的结构，就是模块；按照这种结构划分开发程序的过程，就是模块化开发的过程；
  2. 无论你多么喜欢JavaScript，以及它现在发展的有多好，它都有很多的缺陷：
  • 比如var定义的变量作用域问题；
  • 比如JavaScript的面向对象并不能像常规面向对象语言一样使用class；
  • 比如JavaScript没有模块化的问题

6. 模块化的历史

  1. 在网页开发的早期，Brendan Eich开发JavaScript仅仅作为一种脚本语言，做一些简单的表单验证或动画实现等，那个时候代 码还是很少的：
  • 这个时候我们只需要讲JavaScript代码写到<script>>标签中即可；
  • 并没有必要放到多个文件中来编写；甚至流行：通常来说 JavaScript 程序的长度只有一行。
  1. 但是随着前端和JavaScript的快速发展，JavaScript代码变得越来越复杂了：
  • ajax的出现，前后端开发分离，意味着后端返回数据后，我们需要通过JavaScript进行前端页面的渲染；
  • SPA的出现，前端页面变得更加复杂：包括前端路由、状态管理等等一系列复杂的需求需要通过JavaScript来实现；
  • 包括Node的实现，JavaScript编写复杂的后端程序，没有模块化是致命的硬伤；
  1. 所以，模块化已经是JavaScript一个非常迫切的需求：
  • 但是JavaScript本身，直到ES6（2015）才推出了自己的模块化方案；
  • 在此之前，为了让JavaScript支持模块化，涌现出了很多不同的模块化规范：AMD、CMD、CommonJS等；
  1. 详细讲解JavaScript的模块化，尤其是CommonJS和ES6的模块化。

7. 没有模块化带来的问题

  1. 早期没有模块化带来了很多的问题：比如命名冲突的问题
  2. 当然，我们有办法可以解决上面的问题：立即函数调用表达式（IIFE）
  • IIFE (Immediately Invoked Function Expression)
  1. 但是，我们其实带来了新的问题：
  • 第一，我必须记得每一个模块中返回对象的命名，才能在其他模块使用过程中正确的使用；
  • 第二，代码写起来混乱不堪，每个文件中的代码都需要包裹在一个匿名函数中来编写；
  • 第三，在没有合适的规范情况下，每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况；
  1. 所以，我们会发现，虽然实现了模块化，但是我们的实现过于简单，并且是没有规范的。
  • 我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码；
  • 这个规范中应该包括核心功能：模块本身可以导出暴露的属性，模块又可以导入自己需要的属性；
  • JavaScript社区为了解决上面的问题，涌现出一系列好用的规范，接下来我们就学习具有代表性的一些规范。

8. CommonJS规范和Node关系

  1. 我们需要知道CommonJS是一个规范，最初提出来是在浏览器以外的地方使用，并且当时被命名为ServerJS，后来为了体现它 的广泛性，修改为CommonJS，平时我们也会简称为CJS。
  • Node是CommonJS在服务器端一个具有代表性的实现；
  • Browserify是CommonJS在浏览器中的一种实现；
  • webpack打包工具具备对CommonJS的支持和转换；
  1. 所以，Node中对CommonJS进行了支持和实现，让我们在开发node的过程中可以方便的进行模块化开发：
  • 在Node中每一个js文件都是一个单独的模块；
  • 这个模块中包括CommonJS规范的核心变量：exports、module.exports、require；
  • 我们可以使用这些变量来方便的进行模块化开发；
  1. 前面我们提到过模块化的核心是导出和导入，Node中对其进行了实现：
  • exports和module.exports可以负责对模块中的内容进行导出；
  • require函数可以帮助我们导入其他模块（自定义模块、系统模块、第三方库模块）中的内容；

9. exports导出

exports实现的本质就是引用赋值 image.png image.png 解构使用

image.png

10. module.exports导出

  1. 但是Node中我们经常导出东西的时候，又是通过module.exports导出的：
  • module.exports和exports有什么关系或者区别呢？
  1. 我们追根溯源，通过维基百科中对CommonJS规范的解析：
  • CommonJS中是没有module.exports的概念的；
  • 但是为了实现模块的导出，Node中使用的是Module的类，每一个模块都是Module的一个实例，也就是module；
  • 所以在Node中真正用于导出的其实根本不是exports，而是module.exports； - 因为module才是导出的真正实现者；
  1. 但是，为什么exports也可以导出呢？
  • 这是因为module对象的exports属性是exports对象的一个引用；
  • 也就是说 module.exports = exports = main中的bar；
  1. 结论：node导出的本质，是在导出module.exports对象，require("./foo") export->module.exports，exports导出的本质，本质是在找module中的exports属性的。

const name = 'foo'
const age = 18
function syaHello () {
  console.log("sayhello");
}
// 1. 在开发中使用的很少
// exports.name = name
// exports.age = age
// exports.syaHello = syaHello

// 2. 将模块的内容导出
// 结论：node导出的本质，是在导出module.exports对象，require("./foo") export->module.exports，exports导出的本质，本质是在找module中的exports属性的
// module.exports.name = name
// module.exports.syaHello = syaHello

// 3. 开发中常见的写法
// 这里创建了新对象，不在指向原来的那块地址
module.exports = {
  name,
  syaHello

}

11. require细节

  1. 我们现在已经知道，require是一个函数，可以帮助我们引入一个文件（模块）中导出的对象。
  2. 那么，require的查找规则是怎么样的呢？
  • 这里我总结比较常见的查找规则：
  • 导入格式如下：require(X)

11.1 情况一

  1. 情况一：X是一个Node核心模块，比如path、http
  • 直接返回核心模块，并且停止查找

11.2 情况二

  1. 情况二：X是以 ./ 或 ../ 或 /（根目录）开头的
  2. 第一步：将X当做一个文件在对应的目录下查找；
  • 1.如果有后缀名，按照后缀名的格式查找对应的文件
  • 2.如果没有后缀名，会按照如下顺序：
    • 1> 直接查找文件X
    • 2> 查找X.js文件
    • 3> 查找X.json文件
    • 4> 查找X.node文件
  1. 第二步：没有找到对应的文件，将X作为一个目录
  • 查找目录下面的index文件
    • 1> 查找X/index.js文件
    • 2> 查找X/index.json文件
    • 3> 查找X/index.node文件
  1. 如果没有找到，那么报错：not found

11.3 情况三

  1. 情况三：直接是一个X（没有路径），并且X不是一个核心模块 2
  2. :\work-studing\06-node-webpack-git\02-前端模块化开发\02-module-export中编写 require('why’) 会现在当前的目录下面，去查找node_modules，如果没有找到，会继续往上一层，在查找node_modules,直至查找的根目录下。 image.png
  3. 如果上面的路径中都没有找到，那么报错：not found

12. 模块的加载过程

  1. 结论一：模块在被第一次引入时，模块中的js代码会被运行一次

image.png 2. 结论二：模块被多次引入时，会缓存，最终只加载（运行）一次

  • 为什么只会加载运行一次呢？
  • 这是因为每个模块对象module都有一个属性：loaded。
  • 为false表示还没有加载，为true表示已经加载；
  1. 结论三：如果有循环引入，那么加载顺序是什么？
  2. 如果出现右图模块的引用关系，那么加载顺序是什么呢？ image.png
  • 这个其实是一种数据结构：图结构；
  • 图结构在遍历的过程中，有深度优先搜索（DFS, depth first search）和广度优先搜索（BFS, breadth first search）；
  • Node采用的是深度优先算法：main -> aaa -> ccc -> ddd -> eee ->bbb

ps：Vue中代码的加载顺序： index.html   >  App.vue的export外的js代码   >    main.js调用公共函数外的代码  >   App.vue公共函数的定时器外的代码   >  main.js调用公共函数内创建实例前的代码  >  App.vue的export里面的js代码  >  main.js调用公共函数内创建实例后的代码  >  App.vue公共函数的定时器内执行回调函数后的代码  >   Index.vue的export外的js代码

13. CommonJS规范缺点

  1. CommonJS加载模块是同步的：
  • 同步的意味着只有等到对应的模块加载完毕，当前模块中的内容才能被运行；
  • 这个在服务器不会有什么问题，因为服务器加载的js文件都是本地文件，加载速度非常快；
  1. 如果将它应用于浏览器呢？
  • 浏览器加载js文件需要先从服务器将文件下载下来，之后再加载运行；
  • 那么采用同步的就意味着后续的js代码都无法正常运行，即使是一些简单的DOM操作；
  1. 所以在浏览器中，我们通常不使用CommonJS规范：
  • 当然在webpack中使用CommonJS是另外一回事；
  • 因为它会将我们的代码转成浏览器可以直接执行的代码； 、
  1. 在早期为了可以在浏览器中使用模块化，通常会采用AMD或CMD：
  • 但是目前一方面现代的浏览器已经支持ES Modules，另一方面借助于webpack等工具可以实现对CommonJS或者ES Module代码的转换；
  • AMD和CMD已经使用非常少了；

14. AMD规范

  1. AMD主要是应用于浏览器的一种模块化规范：
  • AMD是Asynchronous Module Definition（异步模块定义）的缩写；
  • 它采用的是异步加载模块；
  • 事实上AMD的规范还要早于CommonJS，但是CommonJS目前依然在被使用，而AMD使用的较少了；
  1. 我们提到过，规范只是定义代码的应该如何去编写，只有有了具体的实现才能被应用：
  • AMD实现的比较常用的库是require.js和curl.js；
  1. require.js的使用(了解)

image.png

15. CMD规范

  1. CMD规范也是应用于浏览器的一种模块化规范：
  • CMD 是Common Module Definition（通用模块定义）的缩写；
  • 它也采用的也是异步加载模块，但是它将CommonJS的优点吸收了过来；
  • 但是目前CMD使用也非常少了；
  1. CMD也有自己比较优秀的实现方案：
  • SeaJS
  1. SeaJS的使用

image.png

avatar
文章
阅读
粉丝