浅谈前端模块化的发展历程

大家好，我是初心，本篇是我坚持原创文章的第01期文章,如有错误，欢迎指正👏🏻

什么是模块化

模块化是将复杂的程序按照一定的规则封装成不同文件，最后组合起来，模块化的内部需要私有化，只像外暴露一些方法使用或于其他模块进行交互。

模块化的优势

• 模块化的内部需要私有化
• 避免命名空间冲突，减少命名污染
• 代码分类更合理化，实现按需加载
• 提高了代码的复用性和维护性

青铜时代，文件划分

我很荣幸经历过青铜时代，那个时候还是jquery的统治，其实那个时候还没有模块化的概念，随着业务的不断扩大，能处理的就是只能通过文件的形式进行划分~

不同页面使用不同的xxx.html文件，分别引入对应xxx.css和xxx.js文件

文件划分的缺陷

• 容易引起全局命名空间冲突

• • 比如 common.js 和 about.js都声明了 format 函数，重复变量等问题

• 代码复用性差

• • 各模块页面使用都需要重复引入需要用到的js文件和css文件 例如jqeury
  • 往往那个时候的开发，像现在的components，只能通过js进行维护~

黄金时代，全局namespace模式

全局namespace模式，通过对象封装模块，在深受环境变量污染全局的困扰之后，团队都开始约束起来，使用对象的形式将逻辑封装起来。

全局namespace的缺陷

• 外部能够修改模块内部数据

• • 外部可以绕开aboutModule.getName方法
  • 通过aboutModule.name进行操作，这违背了模块化的设计初衷

我们该如何解决这个问题？我们可以通过闭包的概念来解决外部修改内部数据的问题

铂金时代,IIFE模式

IIFE(ImmediateIy-invoked function expression)模式是通过自执行函数创建闭包,将逻辑进行封装

值得一提的是立即执行函数是存在作用域的，也就是说name不是挂载到window上，这样我们就可以完美的解决外部修改问题，但是这也带来了新的问题

IIFE的缺陷

• 无法解决模块间相互依赖问题

那么我们又应该怎么去解决模块之间的相互依赖问题呢？我们可以使用外部自定义传参作为依赖

传参虽然能解决问题，但是也有自己的缺陷

• 多依赖传入时，增加阅读成本
• 无法支持大规模的模块化开发，多依赖下，容易混乱~

总结

前端模块化是一个演化的过程，孕育出多个模块化方案，后续还将推出 CommonJS模块化、UMD模块化、ES模块化等等~