React实战-如何构建扁平化的Redux数据结构
2017-04-24 21:51
246 查看
众所周知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时,一般还是采用独立数据模型为好,这样更利于独立开发。共享数据模型看起来很美,但需要较好的前期规划,并且开发成本也更高,量力而行吧。
。
在实际项目开发中,我们往往的经历是:随意性开发->重构->规范化设计,但是理想往往屈服于现实,重构和重新设计的成本总是巨大的,所以每个软件项目都是一个遗憾的缺陷品。解决这种状况的最好办法是采用成熟的设计方法和设计模式。
在初识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时,一般还是采用独立数据模型为好,这样更利于独立开发。共享数据模型看起来很美,但需要较好的前期规划,并且开发成本也更高,量力而行吧。
。
相关文章推荐
- React实战-如何构建React+Flux+Superagent的完整框架
- React实战-如何快速构建一个ReactNative的Demo
- 从12306看如何构建高性能大型网站:高并发集群与负载均衡实战技巧
- Redis实战:如何构建类微博的亿级社交平台
- React全家桶构建一款Web音乐App实战
- 构建NetCore应用框架之实战篇(一):什么是框架,如何设计一个框架
- 如何用 React 构建前端架构
- 【JAVASCRIPT】React学习-如何构建一个组件
- 直播|百安居前端架构师陈国兴:如何使用React构建同构(isomorphic)应用
- 项目实战:如何构建知识图谱
- React Native iOS原生模块开发实战|教程|心得|如何创建React Native iOS原生模块
- React实战-Reactjs中的如何通过不可变数据对象提高页面性能
- 挨踢部落直播课堂第七期:如何使用React构建同构(isomorphic)应用
- React Native移动开发实战-2-如何调试React Native项目
- 开发实战--如何构建简单的英汉词典
- React实战-如何在ReactJs中调用Google、Baidu地图
- 从工程化角度讨论如何快速构建可靠React组件
- 我是如何使用React+Redux构建大型应用的
- react 实战案例(webpack构建)
- React全家桶构建一款Web音乐App实战3