- 以API为设计State的依据（数据重复，数组类型结构不便于查找） 一个API对应一个子State，State的结构砼API返回数据结构保持一致（或接近一致） API是基于服务端逻辑设计的，而不是基于应用状态设计的
- 以页面UI为设计State的依据（数据重复，新增或修改一条记录时，需要修改不止一个地方） 当前应用处于哪种状态，就用对应状态的数据类型的数据渲染UI，不用做任何的中间数据转换
核心原则：像设计数据库一样设计State 把State看做一个数据库，State中的每一部分状态看做数据库中的一张表，状态中的每一个字段对应表的一个字段
设计一个数据库，应该遵循以下三个原则
- 数据按领域分类，存储在不同的表中，不同的表中存储的列数据不能重复
- 表中每一列的数据都依赖这张表的主键
- 表中除了主键以外的其他列，互相之间不能有直接依赖关系
设计State时的原则
- 把整个应用的状态按领域分词若干子State，子State之间不能保存重复的数据
- State以键值对的结构存储数据，以记录的key/ID作为记录的索引，记录中的其他字段都依赖于索引
- State中不能保存可以通过已有数据计算而来的数据，即State中的字段不互相依赖
- 需要额外定义一个状态存储数据顺序
- 除了包含领域数据，还需要包含应用的UI逻辑顺序
- 随着业务逻辑的增加，State第一层级的节点会变得越来越多，这是考虑合并关联性较强的节点数据