前端模块化开发

模块化开发


1. 模块化开发概述

模块化开发目前是当下最重要的前端开发范式之一,模块化并不是一种技术,而是一种开发思想。
模块化将我们的复杂的代码根据功能划分为不同的模块单独去维护,通过这种方式提升开发效率和降低维护成本。

2. 模块化的演变过程

早期的前端技术标准根本没有意识到前端应用能有今天这样的规模,所以很多设计上的遗留问题就导致今天去实现前端模块化会遇到很多问题。当然了,如今都被一些标准或者工具帮助我们解决了这些问题,但是它的演进过程是值得我们去思考的。

  • stage1-文件划分
    最早期的前端模块化是根据文件划分实现的,就是将每个功能的代码单独存放在不同的文件当中,我们约定每个文件就是独立的模块,然后在开发文件引入它们,调用模块的全局成员。但是显然这种方式的缺点是十分明显的,模块内所有的成员都可以在模块外被访问使用或修改,模块一旦多了的话,就难免产生命名冲突,而且我们也无法管理模块之前的依赖关系。总的来说,这种方式全部依靠人为的约定,一旦项目上了体量,这种方式的缺陷就是致命的。

  • stage2-命名空间方式
    文件划分的方式缺陷太多了,所以就有了第二个阶段的模块化,那就是在模块内暴露一个全局的对象,模块内的所有数据都挂载在这个全局对象中。但是这种方式虽然减少了命名冲突的可能,但是仍然没有私有空间,还是没有解决 stage1 的根本问题

  • stage3-IIFE(Immediately-Invoked Function Expression)
    为了解决变量私有化的问题,有些人想到了可以在模块内定义个立即执行函数,私有成员都放在这个立即执行函数中,然后需要暴露出去的成员,我们挂载到一个全局对象中去,这样就实现了私有成员的概念。私有成员我们只能通过模块内闭包的方式去访问,而在模块外部是没有办法去使用的。而且我们还可以通过这个立即执行函数的参数去作为我们的依赖声明去使用,这样就使得我们每个模块的依赖声明显得更加明显了。

以上这些就是早期在没有模块化工具和规范的情况下,我们去实现前端模块化的方式,虽然这些方式帮助我们解决了模块化各种各样的问题,但是它仍然存在一些没有解决的问题。

3. 模块化规范的出现

为了统一不同前端开发者和不同项目的差异,我们就需要一个标准去规范我们实现前端模块化的方式。

  • CommonJS 规范
    了解过模块化的人,肯定知道 CommonJS 规范,它是 Node 实现的的前端模块化规范,它有如下几个约定

    • 一个文件就是一个模块
    • 每个模块都有单独的作用域
    • 通过 module.exports 导出成员
    • 通过 require 函数载入模块
      CommonJS 是以同步方式去加载模块,因为 Node 是在启动时去加载模块,在执行过程中是不需要加载模块的。但是这种方式在浏览器中去使用就会出现问题,如果我们浏览器每次加载页面都有大量的同步模块去加载的话,就会导致浏览器执行的效率特别低下。
  • AMD(Asynchromous Module Definition)规范
    AMD 规范是通过 require.js 实现的,require.js 本身是一个强大的模块加载器。每个模块都需要通过 define 这个函数去定义,这个函数有三个参数,第一个参数是模块的名称;第二个参数是一个数组,用来声明模块的依赖项;第三个参数是一个函数,这个函数的参数与第二个参数的依赖项一一对应,这个函数的作用就是为当前这个模块去提供一个私有空间。

除此之外,require.js 还帮助我们去实现了一个 require 的函数,这个函数帮助我们去载入一个模块。

那么一旦 require 去加载一个模块的时候,他就会去创建一个 script 标签,然后去请求这个脚本文件,并且执行相应模块的代码。目前绝大多数的第三方库都支持 AMD 规范,但是它也有很多缺点:
* AMD 使用起来相对复杂
* 模块 js 文件请求复杂
AMD 只能算是前端模块化演进道路上的一步,它是一个妥协的实现方式,并不能算是最终的解决方案,但是在当时的环境背景下,它还是很有意义的,因为毕竟它为前端模块化提供了一种标准。

  • CMD(Common Module Definition)规范
    CMD 规范是由淘宝的前端团队推出的,它是通过 sea.js 去实现的。它的实现有点类似 CommonJS,在使用上和 require.js 差不多

开始这样设计是为了减少学习成本,后来这种方式也被 require.js 兼容了。

现在前端的模块化标准已经非常清晰了,那就是在 Node 环境中我们遵循 CommonJS 规范,在浏览器中环境中我们会采用一个叫做 ES Modules 的规范。ES Modules 是在 ES6 中实现的模块化标准,所以它会存在各种各样的环境兼容问题,随着 Webpack 等打包工具的普及,这一规范才开始普及。现在 ES Modules 基本已经是前端最主流的模块化规范了,相比于 CommonJS 这种社区规范,ES Modules 可以说是真正在语言层面上实现了模块化。

4. ES Modules 常见特性

目前市面上绝大多数的浏览器都支持 ES Modules,我们想要使用它的特性,只需要在 html 文件中,给 script 标签添加一个 type = module 的属性,就可以用 ES Modules 的标准去执行其中的代码了。下面我们来看看 ES Modules 都有什么特性。

    1. 需要注意的是,在 ES Modules 规范中,自动采用严格模式,不用你手动添加 ‘use strict’,严格模式有一个代表,就是不能在全局环境中使用 this
<script type="module">
    console.log(this) // undefined
</script>
    1. 每个 ES Module 都是运行在单独的私有作用域中
<script type="module">
    var foo = 'bar'
    console.log(foo) // bar
</script>

<script type="module">
    console.
  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值