Question

我有一个app，它与instagram非常相似，但不是一个主要供稿，而是用户可以根据他/她参加的活动有多个Feed。我使用redux进行状态管理目前我有这些减速器：

进料
人
时间表
用户
导航

我的 Feed 缩减器如下所示：

{
  allEvents: [],
  event: {
    id: 123,
    name: 'Foo'
  },
  items: [
    {
      id: 23,
      imageUrl: 'http://img.com/foo',
      likes: [{ id: 1, user: {...} }, { id: 2, user: {...} }],
      comments: [{ id: 1, text: '...', user: {...} }, { id: 2, text: '...', user: {...} }]
    }
  ]
}

所以我的州结构目前看起来像：

{
  feed,
  people,
  schedule,
  user,
  navigation
}

但是，每当用户更改当前事件时，整个Feed状态将被替换为a 该特定事件的新状态，因此如果用户返回上一个事件，则需要整个Feed 要再次获取，同样是人们减速器和时间表，这取决于事件。用户还拥有自己的个人资料Feed，用于显示用户的Feed项。为了得到这个饲料，我愿意我需要复制当前Feed Reducer中的内容，所以我认为最好有多个feed，内部事件减速器。

我想知道这样的州结构是否会更好：

{
  events: {
    items: [
      feed,
      people,
      schedule
    ]
  }
  user,
  navigation
}

然后我读了redux#815或redux#994，这不是筑巢减速器的最好方法。应该看起来更像或更不喜欢：

{
  feed: {
    feedIds: [23, 24, 25],
    byId: {
      23: {
        items: [123, 124, 125]
      }
    }
  },
  items: {
    itemsIds: [123, 124, 125, 126, 127],
    byId: {
      124: {
        id: 124,
        image: 'http://img.com ',
        likes: [1, 2, 3]
      }
    }
  },
  likes: {
    likesIds: []
  },
  events: {
    eventIds: [1, 2, 3],
    byId: {
      1: {
        id: 1,
        name: 'TYW Croatia w34'
        feedId: 23,
        peopleId: 12,
        scheduleId: 1
      }
    }
  },
  people: {...}
}

在这种情况下，最佳做法是什么，哪种方式效果最好？

Answer 1

标准化结构，就像你上一个例子一样，绝对是一种最佳实践，性能更高。状态更平坦，因此更新更有针对性，影响更少的无关对象;根据需要，可以通过ID轻松查找项目;并且更新逻辑通常会更简单。此外，这允许您将项目ID传递给已连接的子组件，然后根据该ID查找自己的数据，并且只需在自己的数据更改时重新呈现它们。最后，它适用于缓存数据。

您可能需要阅读Redux performance上的部分文章，了解更多信息，尤其是High Performance Redux。您可能还想阅读https://github.com/reactjs/redux/issues/1824#issuecomment-228585904上的一些讨论。

编辑：

作为后续行动，我最近在Redux文档中添加了一个关于"Structuring Reducers"主题的新部分。特别是，此部分包含有关"Normalizing State Shape"和"Updating Normalized Data"的章节。

减压器应该嵌套吗？

1 个答案: