React实战-如何构建扁平化的Redux数据结构

系统管理员 2022-06-17 11:15 285阅读 0赞

众所周知React只负责UI的展示，但是数据控制和数据模式也是逃脱不掉的，总是需要自己去实现，总得来说也就那三种方式，在以前的文章中有介绍，但我个人认为还是Redux来的高级点，至少可以采用一个全新的JS实现方式，也值得我们去尝试，Redux采用的是单一数据源，在数据展示时，存在各种不同的展示需求，必然会有不同数据在同一页面展示，不同页面展示同一数据的情况，那么在数据的更新时，也就必然存在不一致，不同步的情况，如何构建一个扁平化的数据结构来适应这种需求呢？weixin公众号：（React实战）

在实际项目开发中，我们往往的经历是：随意性开发->重构->规范化设计，但是理想往往屈服于现实，重构和重新设计的成本总是巨大的，所以每个软件项目都是一个遗憾的缺陷品。解决这种状况的最好办法是采用成熟的设计方法和设计模式。

在初识Redux时，我是连它这种方式都不认可的，采用单一的数据源，想想就疯狂，在开发过程中，我们知道会涉及太多的需要展示的数据，压根不会想这种方式，但别人就这么干了，目前看还有大批的拥护者，当然以老外居多。既然采用单一数据源，开篇的问题也就来了，如何构建满足Redux的数据源？一般来说可以采用两种方式：一种是独立数据模型，一种是共享数据模型。

1.独立数据模型

所谓独立数据模型就是我们每个组件内的数据独立维护，例如人员列表组件包括人员列表、人员数据统计等，其所对应的数据模型独立的占据着Redux数据模型的一个独立分支，数据的读取，转化和更新均取自自身对于的独立数据模型分支，这样也就解决了数据共享带来的问题。

2.共享数据模型

共享数据模型是采用Redux类似的数据模型思想，将数据模型同一规划，系统所有页面均基于同一个Redux数据模型。那么如何解决数据同步问题呢？我们采用关系数据库的原理，数据模型采用扁平化，数据实体间的关联采用ID，而不是具体的数据实体信息，以人员列表举例说明：人员列表包括：人员列表信息，每个人员信息。在常用的列表中是直接装载了人员信息，现在则不是，而是只装载人员ID。

原始人员列表信息json表示：

persons:\[

\{id:1,name:’p1’,age:18\},

\{id:2,name:’p2’,age:13\},

\{id:3,name:’p3’,age:14\},

\{id:4,name:’p4’,age:15\}

....\]

共享数据模型人员列表信息json表示：

Persons:\{

‘1’：\{name:’p1’,age:18\},

‘2’：\{name:’p2’,age:20\},

‘3’：\{name:’p3’,age:13\},

\}，

list:\[‘1’,’2’,’3’\]

\}。

从上面的数据结构就可以看出共享数据模型采用的是关系数据库思想，列表中并没有数据实体，如果单个实体信息变化，并不影响其其它关联数据。但是正如中文换成英文一样，当你采用一种新的表达方式，随之而来将带来新的数据处理方式的变化，甚至有些让你很不习惯，如列表显示不再直接读取，而是需要做一些转变，如id为1的person信息：

独立数据模型：list\[0\].

共享数据模型：persons\[list\[0\]\].

除此之外还有一些另外的操作，包括：查询数据转换、数据更新操作等。你可以自己实现，也可以采用第三方库实现，如：Normalizr库。

正如我之前所说，理想和现实总是有差距的，在初入Redux时，一般还是采用独立数据模型为好，这样更利于独立开发。共享数据模型看起来很美，但需要较好的前期规划，并且开发成本也更高，量力而行吧。

。