JavaScript 模块化

JavaScript 模块化

什么是模块化呢？

• 那么，到底什么是模块化开发呢？
  • 事实上模块化开发最终的目的是将程序划分成一个个小的结构；
  • 这个结构中编写属于自己的逻辑代码，有自己的作用域，不会影响到其他的结构；
  • 这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用；
  • 也可以通过某种方式，导入另外结构中的变量、函数、对象等；
• 上面说提到的结构，就是模块；按照这种结构划分开发程序的过程，就是模块化开发的过程；
• 无论你多么喜欢JavaScript，以及它现在发展的有多好，我们都需要承认在Brendan Eich用了10天写出JavaScript的时候， 它都有很多的缺陷：
  • 比如var定义的变量作用域问题；
  • 比如JavaScript的面向对象并不能像常规面向对象语言一样使用class；
  • 比如JavaScript没有模块化的问题；
• Brendan Eich本人也多次承认过JavaScript设计之初的缺陷，但是随着JavaScript的发展以及标准化，存在的缺陷问题基本都得到了完善。无论是web、移动端、小程序端、服务器端、桌面应用都被广泛的使用；

早期的JavaScript

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

没有模块化带来很多的问题

• 早期没有模块化带来了很多的问题：比如命名冲突的问题

  

• 当然，我们有办法可以解决上面的问题：立即函数调用表达式（IIFE）

  • IIFE (Immediately Invoked Function Expression)

• 但是，我们其实带来了新的问题：

  • 第一，我必须记得每一个模块中返回对象的命名，才能在其他模块使用过程中正确的使用；
  • 第二，代码写起来混乱不堪，每个文件中的代码都需要包裹在一个匿名函数中来编写；
  • 第三，在没有合适的规范情况下，每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况；

• 所以，我们会发现，虽然实现了模块化，但是我们的实现过于简单，并且是没有规范的。

  • 我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码；
  • 这个规范中应该包括核心功能：模块本身可以导出暴露的属性，模块又可以导入自己需要的属性；
  • JavaScript社区为了解决上面的问题，涌现出一系列好用的规范，接下来我们就学习具有代表性的一些规范。

CommonJS和Node

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

案例设定

• 我们来看一下两个文件：

  • 目录结构

    

  • 新建文件夹node，在文件夹node下面新建文件bar.js和main.js（入口文件）

  • 在bar.js中

    const name = "admin";
    
    const sum = (a, b) => {
      return a + b;
    };
    
    // 导出
    exports.name = name;
    exports.sum = sum;
    

  • 在main.js中

    const bar = require("./bar");
    
    console.log(bar.name);
    console.log(bar.sum(10, 20));
    

    // 或者解构导入
    const { name, sum } = require("./bar");
    console.log(name, sum(10, 20));
    

  • 这个时候假如每次修改输出都需要在控制台打印node main.js，这样明显太烦，所以这里需要安装一个热部署nodemon

  • 首先控制台初始化项目npm init -y

  • 安装热部署npm i modemon（局部装置、全局需要加-g）

  • 配置脚本，在package.json中

    {
      "name": "node",
      "version": "1.0.0",
      "description": "",
      "main": "main.js",
      "scripts": {
        "start": "nodemon main.js"
      },
      "keywords": [],
      "author": "",
      "license": "ISC",
      "dependencies": {
        "nodemon": "^2.0.16"
      }
    }
    

  • 控制台输出打印npm start这样随着文件的修改，保存就可以直接打印了

    

exports导出

• 注意：exports是一个对象，我们可以在这个对象中添加很多个属性，添加的属性会导出；

  // bar.js
  const name = "admin";
  
  const sum = (a, b) => {
    return a + b;
  };
  
  // 导出
  exports.name = name;
  exports.sum = sum;
  

• 另外一个文件中可以导入：

  // main.js
  const bar = require("./bar");
  
  console.log(bar.name);
  console.log(bar.sum(10, 20));
  

  上面这行完成了什么操作呢？理解下面这句话，Node中的模块化一目了然

  • 意味着main中的bar变量等于exports对象；
  • 也就是require通过各种查找方式，最终找到了exports这个对象；
  • 并且将这个exports对象赋值给了bar变量；
  • bar变量就是exports对象了；

它们实际上是一个浅层拷贝

• 为了进一步论证，bar和exports是同一个对象：
  • 所以，bar对象是exports对象的浅拷贝（引用赋值）；
  • 浅拷贝的本质就是一种引用的赋值而已；

module.exports又是什么？

• 但是Node中我们经常导出东西的时候，又是通过module.exports导出的：

  • module.exports和exports有什么关系或者区别呢？

• 我们追根溯源，通过维基百科中对CommonJS规范的解析：

  • CommonJS中是没有module.exports的概念的；
  • 但是为了实现模块的导出，Node中使用的是Module的类，每一个模块都是Module的一个实例，也就是module；
  • 所以在Node中真正用于导出的其实根本不是exports，而是module.exports；
  • 因为module才是导出的真正实现者；

• 但是，为什么exports也可以导出呢？

  • 这是因为module对象的exports属性是exports对象的一个引用；
  • 也就是说module.exports = exports = main中的bar；

• 案例分析

  • 在bar.js中

    module.exports.age = 10;
    

  • 在main.js中

    const { age } = require("./bar.js");
    
    console.log(age);
    

  • 控制台打印结果

    

require

• 我们现在已经知道，require是一个函数，可以帮助我们引入一个文件（模块）中导入的对象。

• 那么，require的查找规则是怎么样的呢？

• 这里我总结比较常见的查找规则：导入格式如下：require(X)

• 情况一：X是一个核心模块，比如path、http等内置模块

  • 直接返回核心模块，并且停止查找

• 情况二：

  • 情况二：X是以./或../或/（根目录）开头的

  • 第一步：将X当做一个文件在对应的目录下查找；

    • 如果有后缀名，按照后缀名的格式查找对应的文件

      require('./utils.js') // 这个时候它会直接去找对应的 utils.js 文件
      

    • 如果没有后缀名，会按照如下顺序：

      • 直接查找文件X

      • 查找X.js文件

      • 查找X.json文件

      • 查找X.node文件

        require("./utils");
        // 直接查找 utils 文件
        // 查找是否有 utils.js
        // 查找是否有 utils.json
        // 查找是否有 utils.node
        

  • 第二步：没有找到对应的文件，将X作为一个目录

    • 查找目录下面的index文件

      • 查找X/index.js文件

      • 查找X/index.json文件

      • 查找X/index.node文件

        require("./utils");
        // 查找utils目录下是否有 index.js
        // 查找utils目录下是否有 index.json
        // 查找utils目录下是否有 index.node
        

  • 如果没有找到，那么报错：not found

• 情况三：

  • 情况三：直接是一个X（没有路径），并且X不是一个核心模块（内置模块）

  • 会依次向上去找node_modules

    

  • 如果上面的路径中都没有找到，那么报错：not found

CommonJS规范缺点

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

认识 ESModule

• JavaScript没有模块化一直是它的痛点，所以才会产生我们前面学习的社区规范：CommonJS、AMD、CMD等，所以在ES推出自己的模块化系统时，大家也是兴奋异常。
• ES Module和CommonJS的模块化有一些不同之处：
  • 一方面它使用了import和export关键字；
  • 另一方面它采用编译期的静态分析，并且也加入了动态引用的方式；
• ES Module模块采用export和import关键字来实现模块化：
  • export负责将模块内的内容导出；
  • import负责从其他模块导入内容；
• 了解：采用ES Module将自动采用严格模式：use strict
  • 如果你不熟悉严格模式可以简单看一下MDN上的解析；

案例代码结构组件

• 这里我在浏览器中演示ES6的模块化开发：

  <script src="./modules/foo.js" type="module"></script>
  <script src="main.js" type="module"></script>
  

• 如果直接在浏览器中运行代码，会报如下错误：

  

• 这个在MDN上面有给出解释：

  • https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Guide/Modules
  • 你需要注意本地测试 — 如果你通过本地加载Html文件 (比如一个file://路径的文件), 你将会遇到CORS错误，因为Javascript模块安全性需要。
  • 你需要通过一个服务器来测试。

• 我这里使用的VSCode，VSCode中有一个插件：Live Server

export 关键字

• export关键字将一个模块中的变量、函数、类等导出；
• 我们希望将其他中内容全部导出，它可以有如下的方式：
  • 方式一：在语句声明的前面直接加上export关键字
  • 方式二：将所有需要导出的标识符，放到export后面的{}中
    • 注意：这里的{}里面不是ES6的对象字面量的增强写法，{}也不是表示一个对象的；
    • 所以：export {name: name}，是错误的写法；
  • 方式三：导出时给标识符起一个别名

import关键字

• import关键字负责从另外一个模块中导入内容
• 导入内容的方式也有多种：
  • 方式一：import {标识符列表} from ‘模块’；
    • 注意：这里的{}也不是一个对象，里面只是存放导入的标识符列表内容；
  • 方式二：导入时给标识符起别名
  • 方式三：通过*将模块功能放到一个模块功能对象（a module object）上

Export和import结合使用

• 补充：export和import可以结合使用
• 为什么要这样做呢？
  • 在开发和封装一个功能库时，通常我们希望将暴露的所有接口放到一个文件中；
  • 这样方便指定统一的接口规范，也方便阅读；
  • 这个时候，我们就可以使用export和import结合使用；

default用法

• 前面我们学习的导出功能都是有名字的导出（named exports）：
  • 在导出export时指定了名字；
  • 在导入import时需要知道具体的名字；
• 还有一种导出叫做默认导出（default export）
  • 默认导出export时可以不需要指定名字；
  • 在导入时不需要使用{}，并且可以自己来指定名字；
  • 它也方便我们和现有的CommonJS等规范相互操作；
• 注意：在一个模块中，只能有一个默认导出（default export）；

import函数

• 通过import加载一个模块，是不可以在其放到逻辑代码中的，比如：

  // 这样是不对的 不可行的
  if(true) {
    import sub from './modules/foo.js';
  }
  

• 为什么会出现这个情况呢？

  • 这是因为ES Module在被JS引擎解析时，就必须知道它的依赖关系；
  • 由于这个时候js代码没有任何的运行，所以无法在进行类似于if判断中根据代码的执行情况；

• 但是某些情况下，我们确确实实希望动态的来加载某一个模块：

  • 如果根据不懂的条件，动态来选择加载模块的路径；
  • 这个时候我们需要使用import()函数来动态加载；

CommonJS的加载过程

• CommonJS模块加载js文件的过程是运行时加载的，并且是同步的：

  • 运行时加载意味着是js引擎在执行js代码的过程中加载模块；

  • 同步的就意味着一个文件没有加载结束之前，后面的代码都不会执行；

    // CommonJS 语句是可以写在逻辑代码里面的
    const flag = true;
    if (flag) {
      const foo = require("./foo");
      console.log("if语句继续执行");
    }
    

• CommonJS通过module.exports导出的是一个对象：

  • 导出的是一个对象意味着可以将这个对象的引用在其他模块中赋值给其他变量；
  • 但是最终他们指向的都是同一个对象，那么一个变量修改了对象的属性，所有的地方都会被修改；

ES Module加载过程

• ES Module加载js文件的过程是编译（解析）时加载的，并且是异步的：

  • 编译时（解析）时加载，意味着import不能和运行时相关的内容放在一起使用：
  • 比如from后面的路径需要动态获取；
  • 比如不能将import放到if等逻辑语句的代码块中；
  • 所以我们有时候也称ES Module是静态解析的，而不是动态或者运行时解析的；

• 异步的意味着：JS引擎在遇到import时会去获取这个js文件，但是这个获取的过程是异步的，并不会阻塞主线程继续执行；

  • 也就是说设置了type=module的代码，相当于在script标签上也加上了async属性；

  • 如果我们后面有普通的script标签以及对应的代码，那么ES Module对应的js文件和代码不会阻塞它们的执行；

    <script src="./modules/foo.js" type="module"></script>
    <!-- 这个js文件的代码不会被阻塞执行 可以同时执行 -->
    <script src="main.js" type="module"></script>