请教老师 如何设计 多级嵌套关联（含反向）的 state 数据结构？
来源：4-2 设计应用state
小蜗牛不回头
2019-03-11
首先感谢老师的良心教学，收获很大！都是硬核的知识点呀！
学过课程后，我非常兴奋！所以现在尝试做一个 仿 外卖点餐 的案例。
其中遇到一个问题是：数据结构有多级别嵌套，且其中有些节点的数据不涉及增删改的操作。
实施上，
如果全部按 扁平化 *依葫芦画瓢 *的话，是否永无止尽（指工作量，因为扁平化的目的仅是方便检索与操纵，不知我的理解对吗？）？
比如这个案例：
（类别 1 ：n 商品 ）（商品 1 ：n 规格）（规格 1 ：n 商品）
（商品 1 ：n SKU) （SKU 1 ：n 规格）（规格 1 ：n SKU)
特别是，选择 规格 拼凑成 SKU 这一过程的操作感觉特别复杂！（这里不知该如何设计结构了？）
望老师指教一二！感谢！
1回答
-
你好。
首先，扁平化的目的不仅是方便检索和操作，更重要的是保证数据一致性：当对某个数据进行了修改后，所有使用的该数据的地方都能同步的更改。例如，假设在多个嵌套数据中都包含商品数据，对某个嵌套数据中的商品进行修改，是不会影响到其他嵌套数据中的商品的。
你举的例子中，如果类别、商品、规格等都需要多个字段描述，那么它们都应该是一个独立的领域实体（可以理解成一张数据库表），不同实体中的联系通过id关联。例如，商品实体中，有规格属性，保存的是规格的id数组；规格实体中，也可以有商品属性，保存商品的id数组。
这样做是会比较麻烦，但状态管理本身就是一件复杂的事情。想象一下，如果你是负责后台开发的同学，这些关系应该如何映射到数据库表中呢？前端的状态管理本质上和后端的数据库表设计是类似的。
当然，因为你的demo中不涉及数据的修改，所以也不一定要彻底的进行扁平化设计。只是展示数据，其实并不算状态管理，所有的状态还是依赖后端管理的，这样前端直接使用嵌套数据展示也是没有问题的。
最后，一切解决方案都是服务于某种业务场景的，要活学活用，不要把知识学“死”了。
祝学些顺利！
112019-03-12
相似问题