我一直在努力学习如何更好地构建我的Redux商店,并偶然发现了Dan的这一课。Redux - 为什么正常化?
https://egghead.io/lessons/javascript-redux-normalizing-the-state-shape#/guidelinesModal
虽然我知道如何去用这种方式正常化我的数据,我不明白它背后的动机。特别是,我有两个问题。
为什么不简单的数组就足够了? Dan提到 - “在复杂的应用程序中,我们可能不止一个数组,而且在不同阵列中具有相同ID的待办事项可能会不同步”。我不明白这一点,我可以举个例子吗?我从使用对象看到的唯一好处是提高了效率,因为我们不需要映射整个数组,以防我想将某个待办事项委托给另一个还原器。
为什么我们需要维护一个allIds列表?为什么要保持这个额外的状态,当我们可以很容易地映射所有待办事项清单并获得它?
我知道normalizr为我们做了这个,但为什么我们应该正常化呢?即使响应没有深度嵌套,规范化是否有意义?
编辑1:
谢谢您的回答,克里斯托弗。
让我们假设你的状态树是这个样子
{
user: {
byId: {
1: {
id: 1,
name: 'Buy stuff'
},
2: {
id: 2,
name: 'Yeah'
}
}
},
allIds: [1, 2],
subscribedIds: [5],
}
department: {
byId: {
5: {
id: 5,
name: 'Sell Stuff'
}
},
allIds: [5],
subscribedIds: []
}
}
我没有看到发生在这里的数组具有对象的利益。我也可以有一些选择器,即使它是一个数组,也可以通过ID从部门获取订阅的待办事项。看来我对这个概念的理解有点不足。你能否详细说明一下?
是的。关于你最后的问题,如果你理解你,只需要一个浅层对象而不是对象层次结构的数组就可以工作。 但是,如果您最终在数组中有* lots *项,并且您经常执行“find this id”操作,则每个数组查找都是O(N)。将您的对象放入哈希结构中,而不是使查找O(1)...显着更快。 –
完美!谢谢。 –
对于任何想要了解更多关于该主题的文献,您可以参考http://redux.js.org/docs/FAQ.html#organizing-state-nested-data和链接的文章。 –