一、React+Redux 项目结构
二、Redux 演变过程
- 混乱结构 -> 组件化结构
- 插件引用 -> 模块化工程
- MVC -> MVVM
- 零散状态管理 -> 全局状态管理
- 双向数据流 -> 单向数据流
前言
Web前端模块化的发展历程，也就是开发人员组织代码结构，提高项目可维护性的过程。JavaScript 语言因为出生过于随性，引发了非常多的历史遗留问题。而最大的缺憾就是，没有考虑语法层面的模块组织结构，致使其在很长一段时间内只能作为寄生于网站页面的脚本语言，发挥着玩具一般的简单动效。直到有一天，不堪忍受的开发者们膝盖纷纷中箭。
2.1 原始时代：冲突纷争
模块化演变的历程中，是以 JavaScript 为核心，逐渐深化为 多种文件打包 ，不过这是后话。在原始时代（其实也没过多久），Web前端的开发者们通常将 JavaScript 代码直接写入 html 页面，常见的方式如：
<html>
<head>
<meta charset="utf-8">
<title>Example</title>
</head>
<body>
<div id="root"></div>
<script type="text/javascript">
// 此处省略一万行 JavaScript 代码...
</script>
</body>
</html>
如同这样，简单的页面嵌入简单的代码片段，可能感受不到什么影响。但做个假设，这里的 JavaScript 代码真的有一万行，花了你2个月的时间进行开发和改善。你会发现，随着代码量增加，维护成本逐渐提高。甚至你自己都找不到一些逻辑究竟在写在了哪里。
同时，这样的开发模式完全不适合多人协作。如果这里的一万行代码交给两个人来写，很明显的冲突就是：变量或函数命名冲突、重复处理的业务逻辑、业务处理的时序性混乱等。
此时有的同学可能会站出来，将一些业务逻辑写入到独立的 js 文件之中，页面代码变成了这个样子：
<html>
<head>
<meta charset="utf-8">
<title>Example</title>
</head>
<body>
<div id="root"></div>
<script type="text/javascript" src="biz01.js">/script>
<script type="text/javascript" src="biz02.js">/script>
<script type="text/javascript" src="biz03.js">/script>
</body>
</html>
如果在每一个 bizXX.js 之中，并没有专门去处理作用域冲突（闭包），那么以这样的方式构建的页面脚本，仅仅解决了不同的 <script> 标签加载时序不同，引发的一些声明没有提升的问题，而完全无法从根本上解决冲突。
2.2 插件时代：闭包
随着20世纪末，至21世纪初，越来越多的人关注并且开始利用互联网获取信息，浏览器的使用率也越来越大。越来越多的公司或团体希望全世界能看到自己，纷纷开始建立自己的网站，用于展示企业或团队形象，以及展示产品和服务。
横向对比，假设越来越多同质化的展示产品的网站涌现，就会令其价值稀释。因此一些团队希望让自己的网站显得与众不同。市场的需求也在进一步推动技术革新，在Web视觉层面，快速构建复杂的网站视图特效也成为了当务之急。
很多团队提出了自己对于更快更好的构建Web前端工程的解决方案，其中最为著名的比如Sam Stephenson编写的类库 prototype.js 、John Resig发布的类库 jQuery.js。纵观这些优秀的解决方案，无一例外的使用着闭包特性解决着一些引用冲突问题。
那么什么是闭包呢？详细了解请参考我的另一篇文章《JS 函数式编程思维简述(四)：闭包（Closure）》。简而言之，闭包是 JavaScript 语言支持函数式编程的重要基石。闭包特性最主要解决两个问题：
- 缓存闭包函数内部数据，对外导出；
- 保证函数内部变量引用的准确性（就近引用原则）；
以 jQuery 源码为例：
( function( global, factory ) {
"use strict";
if ( typeof module === "object" && typeof module.exports === "object" ) {
module.exports = global.document ?
factory( global, true ) :
function( w ) {
if ( !w.document ) {
throw new Error( "jQuery requires a window with a document" );
}
return factory( w );
};
} else {
factory( global );
}
} )( typeof window !== "undefined" ? window : this, function( window, noGlobal ) {
// 此处省略一万多行...
if ( !noGlobal ) {
window.jQuery = window.$ = jQuery;
}
return jQuery;
} );
无论 jQuery 现在的市场角色如何，其学习价值都是非常大的。通过闭包的方式，我们解耦了 js 代码片段之间的关系，只有在需要时才进行互相引用。以此作为基石， jQuery 团队又推出了自己的UI插件库 —— jQuery-ui，以及鼓励开发者们以 jQuery 为地基构建自己的功能性插件。著名的如瀑布流特效插件Masonry、以及 Bootstrap 团队提供的 UI 插件等。
无论是以何种方式来构建插件，其基准原则都是：加强内聚、减少耦合、减少冲突。而诸多插件的引入，也形成了插件时代独特的代码组织结构风格。
2.3 模块时代（初期）：大乱斗
插件时代通过不同的闭包环境来构建整体应用，因此一个网页内部结构经常是这个样子的：
<html>
<head>
<meta charset="utf-8">
<title>Example</title>
</head>
<body>
<div id="root">
<!-- 省略以前多行代码... -->
</div>
<script src="https://cdn.jsdelivr.net/npm/jquery@1.12.4/dist/jquery.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@3.3.7/dist/js/bootstrap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/jquery-unveil@1.3.2/jquery.unveil.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/markgoodyear/scrollup@2.4.1/dist/jquery.scrollUp.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/@firstandthird/toc@1.4.1/dist/toc.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/jquery-match-height@0.7.2/dist/jquery.matchHeight-min.js"></script>
...
</body>
</html>
插件的独立引用为构建大型Web应用视图提供了可行性，但长期的实践过程中，我们发现这并不是一个最好的解决方案，主要暴露出的问题是：
- 插件之间的引用次序边界模糊；
- 插件之间构建和调用方式风格迥异；
- 增加了页面额外文件的请求频次;
- 团队协作时容易引发插件版本或其他引用问题；
- ...
有待解决的问题产生，就有解决问题的人出现，因此，Web前端工程的模块化的呼声也越来越响。TC39 （ECMA-262标准制定委员会）官方迟迟没有改进方案，那么只能由民间高手们自发制定模块化方案。
模块化最主要的表现形式为：
- 规范了独立功能的对外引用（导出）方式；
- 规范了独立功能的内部引用（导入）方式；
- 规范了独立功能的依赖加载次序；
最著名的Web前端模块化方案要数 AMD规范和CMD规范，具体示例请参考我的另一篇文章《JS 函数式编程思维简述(四)：闭包之流行的模块化方案》。以 Alibaba 的前辈玉伯所设计的 Sea.js 作为示例：
demo目录结构：
// 当前示例的目录结构
├─ js
│ ├─ sea.js
│ ├─ aa.js
│ ├─ bb.js
│ └─ cc.js
├─ index.html
模块引用方式：
<script src="js/sea.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript">
// 通过 seajs 对象调用 use() 方法获取其他模块的引用
seajs.use('./js/aa.js', function (aa) {
aa.printBB();
aa.printCC();
});
// 未阻塞的页面其他 js 语句
console.log('page loaded...');
</script>
无论是何种 模块规范，都秉持统一的一个理念：整体项目通过一个主入口进入，通过对其他模块的依赖来按需加载。熟悉 Java 的同学可能会想到 Java 项目中的 main() 方法，的确设计理念是一致的。
这些模块方案解决了两个重要的问题：统一的模块依赖次序、统一的模块编码风格，为 JavaScript 模块化进程奠定了基础。
2.4 模块时代（中期）：趋于一统
天下大势，合久必分，分久必合。在 Web前端模块化趋于一统的进程中，出现了三个重要的技术影响，他们分别是node.js、webpack、ES6模块机制。
2.4.1 node.js 和 CommonJS规范
node.js是一个非常神奇的产物，是融合了性能变态的Google V8引擎、C++底层，通过 JavaScript 编写可涉足于多个领域能力的运行平台，其研发的初衷是为了更快的创建异步的高性能的web应用服务。其本身扩展了诸多 JavaScript 能力，同时以 CommonJS 作为模块化规范，定义了项目中解构出的独立文件的依赖方式：
典型的 node.js 代码：
// 模块导入
let fs = require('fs');
// 定义一个读取文件返回 Promise 对象的异步函数
let readFile = (txtOrig) => new Promise((resolve, reject) => {
// 使用导入的模块 fs
fs.readFile(txtOrig, {encoding: 'utf8'}, (err, data) => {
if(err) reject(err);
resolve(data);
});
});
// 模块导出
module.exports = {
readFile
}
在一段时间里，node.js 中使用的 CommonJS 模块通常被称之为是服务器端模块化方案，而 Web前端 所应用广泛的 AMD 和 CMD 则通常被称之为是前端模块化方案。原本互不影响的两个应用领域，随着 webpack 技术的成熟，产生了命运的交汇。
2.4.2 webpack
webpack是一种文件打包合并技术，是 node.js 工程中常用的构建工具。原理是通过分析待打包的依赖文件关系，将数个文件合并成一个整体文件。引用 webpack 官方网站 的简单示例：
待合并的文件：
// ./src/bar.js
export default function bar() {
console.log("bar...");
// do something...
}
// ./src/index.js
import bar from './bar';
bar();
配置打包方式：
// ./webpack.config.js
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: 'bundle.js'
}
};
最终生成合并后的文件：
// ./dist/bundle.js
!function(e) {
var t = {};
function r(n) {
if (t[n]) return t[n].exports;
var o = t[n] = {
i: n,
l: !1,
exports: {}
};
return e[n].call(o.exports, o, o.exports, r),
o.l = !0,
o.exports
}
r.m = e,
r.c = t,
r.d = function(e, t, n) {
r.o(e, t) || Object.defineProperty(e, t, {
enumerable: !0,
get: n
})
},
r.r = function(e) {
"undefined" != typeof Symbol && Symbol.toStringTag && Object.defineProperty(e, Symbol.toStringTag, {
value: "Module"
}),
Object.defineProperty(e, "__esModule", {
value: !0
})
},
r.t = function(e, t) {
if (1 & t && (e = r(e)), 8 & t) return e;
if (4 & t && "object" == typeof e && e && e.__esModule) return e;
var n = Object.create(null);
if (r.r(n), Object.defineProperty(n, "default", {
enumerable: !0,
value: e
}), 2 & t && "string" != typeof e) for (var o in e) r.d(n, o,
function(t) {
return e[t]
}.bind(null, o));
return n
},
r.n = function(e) {
var t = e && e.__esModule ?
function() {
return e.
default
}:
function() {
return e
};
return r.d(t, "a", t),
t
},
r.o = function(e, t) {
return Object.prototype.hasOwnProperty.call(e, t)
},
r.p = "",
r(r.s = 0)
} ([function(e, t, r) {
"use strict";
r.r(t),
console.log("bar...")
}]);
此时，我们便可以在页面这样引用：
<!doctype html>
<html>
<head>
...
</head>
<body>
...
<script src="dist/bundle.js"></script>
</body>
</html>
即便源代码非常简洁，合并后的文件 bundle.js 也显得非常复杂。webpack 在打包的过程中会递归地构建一个依赖关系图，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。打包合并后的独立文件，是一个内部包含完整的模块引用及运作的闭包环境。
早期的Web前端模块化方案是这样的：
借助于 webpack 的 Web前端 工程方案是这样的：
可以看到，之前的方案中对于模块的引用是采用按需动态引用，支持了模块化的方式进行开发，提高了工程的可维护性。但并未有效的降低依赖文件的请求次数，缓解页面请求压力。
借助 webpack ，我们通常在开发阶段就把所有的模块合并成为了一个 js 文件。在项目上线运行的生产环境，通常只需要加载一个 bundle.js 文件即可，大大缩减了开发过程模块化对于运行过程的影响。 webpack 真的是帮我们做了很多事。时至今日，AMD和CMD模块化支持的使用率正在逐步减少，因为 webpack 打包过程是基于 node.js 运行环境中的，直接使用 CommonJS 规范进行工程模块构建即可。
2.4.3 ES6模块化定义：未来
终于，TC39 在 ES6（也称ES2015）中定义了官方推荐的模块化方案，部分浏览器厂商也逐步开始支持。即使你的浏览器环境或者nodejs环境无法支撑ES6模块化语法，也可以通过诸如 Babel、TypeScript等工具直接体验新版本的开发过程。关于ES6模块的简单示例，可参阅我的另一篇文章《JS 函数式编程思维简述(四)：闭包之流行的模块化方案》。
CommonJS 规范 因为 node.js 而大肆盛行于Web前端和服务器端，但作为 ECMA 制定的官方模块化规范，相信 node.js 团队也会加快脚步，尽快完成对其支持。
结束语：模块化是构建复杂应用的基础，JavaScript 的模块化支持，是其从玩具语言转变成为功能强大的编程语言过程中的重要里程。
