我一直在尝试学习如何更好地构建Redux商店,但偶然发现了Dan的这一课。
https://egghead.io/lessons/javascript-redux-normalizing-the-state- shape#/guidelinesModal
尽管我了解如何以这种方式标准化我的数据,但我不了解其背后的动机。特别是,我有两个问题。
为什么简单数组不足够?Dan提到-“在复杂的应用程序中,我们可能有多个阵列,而在不同阵列中具有相同ID的待办事项可能会不同步”。我不明白这一点,请问有个例子吗?使用对象看到的唯一好处是提高了效率,因为如果我想将某个待办事项委托给另一个reducer,则不需要映射整个数组。
为什么我们需要维护allId列表?当我们可以轻松地绘制所有待办事项列表并获取它时,为什么还要维持这种附加状态?
我知道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来获取订阅的待办事项。我对这个概念的理解似乎有些不足。您能详细说明一下吗?
例如,您可能同时有一个TODO(例如ID为1),它位于“用户的TODO”列表和“部门的TODO”列表中。然后,如果用户更新了她的待办事项,那么该“待办事项”也应该在“部门的待办事项”列表中进行更新。如果您的数据被规范化,则TODO将会在两个地方都进行更新(嗯,实际上只有一个TODO实例可以从多个地方简单地引用)。但是,如果未规范化,部门将拥有待办事项的陈旧副本。
老实说,我认为您是对的。如果您要麻烦规范化,那么复制ID列表似乎与该工作背道而驰。
无论如何,我认为在React中对数据进行规范化的情况可能与总体上对数据进行规范化的情况(例如,在数据库中)相似。前面需要付出更多的努力,但是它给您带来的灵活性通常是值得的。
另外,我并不总是对我的React代码进行规范化,但是我发现 不 规范化最终会使我的代码随着时间的推移变得更加草率。我只是变得自律。我想这就像破窗效应。在非规范化代码中,我只是开始将值扔到它们确实可能不应该仅仅是出于方便而已的地方。