最近完成了一个使用 React Redux 组合的项目，以前仅仅是接触了解以及学习，并未正儿八经地使用过，因此这一次可以说是第一次完整地再一个项目当中使用。因而对于认识之浅显请轻拍。
从架构和层次的层面，这个组合给我最好的感受是干净利落的解耦。有不少 JavaScript 框架尝试解决解耦问题，但是到了落实的层面上很容易出现分层分模块不容易严格控制，缺少清晰标准等问题。但是 React Redux 的组合没有这个问题，我们把应用中 JavaScript 的部分分层为 action、client、config、constant、reducer、store、util 和 view 几个部分，其中 view 又进一步划分成 component（不带业务逻辑）和 widget（包含业务逻辑）等几个子包。每一个小模块对应有规约路径和命名的 scss，在应用中基本上没有出现层次混乱的情况。当然也不尽美，其中一个容易混乱的地方在于传递的数据模型的设计，比如从服务端取回的对象，之后的数据处理可以放在 action 中，可以放在 reducer 中，甚至也可以放在 view 中——这是由（1）“到底想给 reducer 传递怎样的消息” 和（2）“在 store 中要存储怎样的数据结构” 来决定的。这一条标准的理解不同，容易引起不同的代码风格和不同的层次模块划分。
我们有一些新员工初涉 JavaScript，我觉得应用 React Redux 组合的代码是非常好的 “第一个项目”，因为相对来说稍微严格一些的代码控制和清晰的层次模块划分，对于培养良好的设计和代码习惯有着非常大的作用。本来前端的世界里面就是良莠丛生，容易上手但是水又深，相对代码自由度高，而且杂七杂八的风格范型到处都是。培养一个好的习惯在职业生涯中受益无穷。
再吐槽关于 view 的一切都由 store 中的状态决定这一点。其实这个初衷非常好，特别利于解耦，view 可以划分到很小的模块，只有零零散散几个状态，并且问题定位的时候可以牢牢抓住状态变化这一点。但是凡事有利有弊，在大型项目的时候这一点明显增加了可维护性，但是也明显让项目的代码显得臃肿。基本上每添加一个小小的功能，都要从 action->reducer->view 等等一层一层写好多代码。如果遇到了一些特殊的情形，比如需要一些动画效果，真可谓杀鸡用牛刀，逻辑繁琐。以前也用过一些其他框架，比如 Angular 等等，如果从代码量上看，Redux 可以说是比较多的，如果你喜欢简洁清晰的代码，不喜欢一大堆 js 文件，那么你不会喜欢 Redux 的。
关于 JSX。React 中 JSX 可谓是最大的创新了，我本人也非常喜欢这种不同编程范型的融合（命令式代码和声明式代码）。如果有一个好的 IDE 插件，编码的过程是非常愉悦的。同时，JSX 和 JS 一样，测试非常方便，通常我们把测试用例和源码放在一起，只是每一个测试子包以 “_test” 命名，这一点非常利于源码和测试代码关联起来阅读。
最后赞一下 Redux 的 devtools，非常好用。结合起一些其他辅助测试的工具，我们现在基本上在开发模式下每当有任何源码的改动，或者 UT 的改动，改动影响到的 UT 会在后台自动运行，并且调试页面会自动加载改动的内容，省去了传统模式下 build-deploy-refresh 的过程。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
