前端数据层的探索与实践（一）

第一部分：前端数据层的探索与实践（一）
第二部分：前端数据层的探索与实践（二）

契机

在使用redux的过程当中，因为业务复杂度的提高，store里面存储的数据愈来愈多，一般会有多层次的嵌套和重复数据。同时在与后端交互的过程当中，咱们常常会讨论是否要按照UI的层次结构来返回数据，结果被后端驳回，由于若是后端从数据库中取到数据后，还要特地为前端加一层转换，一来是考虑到服务器压力，二来是考虑到多设备的时候没法复用接口。

在这样的契机之下，我开始思考，面对复杂的应用，前端也须要处理业务逻辑，那么数据应该如何组织和管理？

三种方案

• 中间层BFF（Backend for Frontend）模型

• GraphQL

• 范式化数据

此次我先讲范式化数据。

范式化

所谓“范式化”，就是数据库设计时使用的一系列原理与技术。在讲范式以前，咱们先说一下你们都不陌生的关系型数据库，这就是应用范式化的典型。

关系型数据库：创建在关系模型上的数据库。

关系模型：若干个存储数据的二维表，每一行称为一条记录，每一列称为一个字段。表与表之间用关系来描述，有一对一/一对多/多对多三种关系。

借此两个概念很容易想到咱们接触得很是多的数据库。那关系型数据库在存储和管理数据的时候遵循哪些原则呢，见下：

第一范式（1NF）：表列（或称属性或称字段）具备原子性，不可再分。

第二范式（2NF）：知足1NF的前提下，表行（或称实例）必须具备惟一能够被区分的主键key

第三范式（3NF）：知足1NF&&2NF的前提下，每一个表中不包含已在其余表中定义的非关键字段，也就是不能有冗余数据。

前端范式化数据

明白了范式化的概念与设计原则，咱们以Redux应用为例，看一下咱们应该怎样设计范式化数据，先看一个简单的例子，咱们组织数据一般是这样：

咱们分析以上这个例子，能够看出实体有article/author/comment/commenter，对应设计为数据库表的时候能够建三张表user/comment/article，因此范式化数据应该像这样：

总结：

• 每种类型的数据应该具备本身的表,
• 每张表存储在对象中，对象中的每一个元素即为一条记录，用id做为key,数据内容做为value
• 数据A与数据B的关系经过ID来描述

这样带来的好处显而易见：

• 数据更加扁平化，最多只有一层
• 数据间的关系清晰
• 数据项是惟一的，减小冗余
• reducer再也不须要深层次嵌套处理数据
• 更新数据项时，更新只会发生在当前项，不会对引用该数据项的地方作无必要的重复渲染
• 每一个组件能够connect本身的数据，无需一层一层的向下传递数据（可提升性能）

应用

当服务器端把数据传到前端的时候，咱们不太可能手动的去把这些数据范式化，好在咱们已经有了不少成熟的库，帮咱们作转化。在Redux应用中，推荐比较多的就是 Normalizr 了，这个库主要是帮咱们将数据作范式化处理，输出的数据能够放在state中，显然，这样的范式化数据在store中进行手动处理，会很是不方便，也有这样的库来帮助咱们解决范式化数据在store中的问题，好比Denormalizr。可是还有一个更好的工具，Redux-ORM，它能够说是Normalizr和Denormalizr的结合（若是是vue，也有相似的工具vuex-orm）。

结束语

一直认为学习要在熟悉掌握基础的前提下多加实践，因此我这一部分只是讲了一些范式化的基础概念，同时引出生态链中与此相关的受欢迎的库。第二部分我将详细讲一下个人Redux-ORM实践。欢迎小伙伴们一同探讨👏

参考资料：

cn.redux.js.org/docs/recipe…

zhuanlan.zhihu.com/...

redux.js.org/faq/organiz…