最近完成了一个使用 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 的过程。
文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》
react+redux 我也玩了一圈。分层解耦明显,工程非常清晰。
代价就是每写一个 component 都要带入一套 action,reducer,当然简单组件不想用 redux 也可以不走 connect,这是可选的。
同意!这是容器组件和展示组件相分离的典型例子。如果疲于写文中提到的 action->reducer->view 的层层代码,楼主可以尝试一下 dva 框架,它将 action 和 reducer 封装到 model 当中去了,简化了不少。
码工中我就服写 Javascript 的!