04|模块化React和Redux应用
创建一个复杂的应用应该如何做,如下包含了四点:
- 模块化应用的要点
- 代码文件的组织方式
- 状态数的设计
- 开发辅助工具
01|模块化应用的要点
从架构角度来看的话,开发一个新的应用的时候,有几件事情时一定要考虑清楚地:
- 代码文件的组织结构
- 确定模块的边界
- Store状态树的设计
02|代码文件的组织方式
- 按照角色组织
- 如果是按照对应的MVC框架的模式进行开发的话 MVC三层的文件夹目录结构你想必不陌生!
- 将对应的代码放入到不同角色的文件夹下面!
- 对应的React和Redux中的角色组织管理是通过 reducer 和 action 和 Components 以及对应的containers组成!
- 但是这样的角色(MVC) 关系会导致角色之间的交叉关系,但是在Redux中的话,我们会以一种比较严格模块化的思想的文件组织方式!
03|按照功能组织
对应的按照功能模块划分,对应的一个功能就会有对应的功能模块,增加模块会直接在新的文件夹里面添加代码不会对别的文件夹里面的代码产生影响! 按照功能进行划分也是一种好的管理方式!
04|模块接口
在最理想的情况下,我们应该通过增加代码就能够增加系统的功能,而不是通过现有代码的修改来增加功能!
对应的在不同模块下通过接口暴露功能模块!
一个功能模块(以文件夹为单位)以接口的形式暴露接口!
todolist
|
index.js //作为接口暴露出功能对象 并且包括 action和reducer以及container!
|
action.js
|
reducer.js
|
views/container.js
05|状态树设计
状态树的设计应该包含如下几点设计原则:
- 一个模块控制一个状态节点
- 避免冗余数据
- 树形结构扁平
- 状态节点只属于一个模块
每个模块对应自己的一个reducer用来修改对应的数据,避免两个reducer修改同一个状态树上的节点!
- 避免冗余数据
冗余数据的话可能会给数据保持一致性带来挑战,因此避免数据冗余是一个比较重要的原则!
本文中对数据库选择范式化和非范式化的概念没有做过多的阐述,对应的! 范式化就是传统数据库的一个比较鲜明的概念 避免了数据的冗余 但是现在的NOSQL是去范式化的,提倡在数据库中冗余,来减少读取数据库时的 数据关联工作, 对于性能上面还是有一定的提升!
但是在不考虑数据库选型的前提下面,前端的Redux的store中,一定要避免数据冗余的出现!
不考虑性能的前提下面,数据一致性才是我们要中关注的问题!
- 树形结构扁平
对应的树形结构可以有很深层次的结构,但是设计Redux的Store的时候,尽量保持对应的树形结构层次比较扁平
如果说想要访问节点D,树形结构从上往下有A,B,C节点的时候,再去数据的时候就可能需要一次进行判断!
const D = state.A && state.A.B && state.A.B.C && state.A.B.C.D
对应的代码中,其中有些点是需要我们仔细去了解的,比如说: JSX中不能够写for或者说while! 只能够使用JS表达式! 当然还有通过对应的在列表渲染的过程中通过key做标识,能够更加精确的对节点进行diff操作!
对应的在组件之外提到了关于样式的处理: extract-text-webpack-plugin 可以让对应的CSS文件在Build的时候,放在独立的文件中,而不是嵌入最终的打包文件Bundle中! 将对应的CSS文件拆分出来让打包文件更小!
还有对应的ref的用法,在React中的出现本身就是为了避免操作DOM而出现的, 对应的ref本身在React中的应用场景不多,对应的用的地方在form地方比较多!
直接操作DOM元素的情况下,很容易让元素产生失控的情况!
对应的利用组件同步记录DOM元素的值,这种方式可以控制逐步使用ref!
通过事件和事件处理器的方式对齐状态进行改动!
06|开发辅助工具
对应的稳重推荐了几款工具来辅助我们开发React应用:
- React DevTools
- Redux DevTools
- React Perf 监视对应的React渲染的性能问题!
对应的不仅如此,我们还可以通过 redux-immutable-state-invariant 能够让我们派发动作之后做对应的检查!
对我们在Reducer的编写做一定的约束和规范操作! 对应的reducer作为纯函数的时候,是不能够出现副作用的!
对应的插件以及对应的使用方法可以借鉴文档予以解决!
缩小代码的插件 UglifyJsPlugin 通过对变量的处理在功能不受影响的前提下对代码体积进行优化!
