减速器应该嵌套吗? [英] Should the reducers be nested?

查看:39
本文介绍了减速器应该嵌套吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 应用,它与 instagram 非常相似,但用户没有一个主要的提要可以根据他/她参加的活动有多个提要.我正在使用 redux 进行状态管理目前我有这些减速器:

I have an app which is very similar to instagram, but instead of having one main feed, the user can have multiple feeds based on the events he/she attends. I'm using redux for the state management and currently I have these reducers:

  • 饲料
  • 日程
  • 用户
  • 导航

我的 feed 减速器看起来像:

My feed reducer looks like:

{
  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: {...} }]
    }
  ]
}

所以我的状态结构目前看起来像:

So my state structure currently looks like:

{
  feed,
  people,
  schedule,
  user,
  navigation
}

但是现在每次用户更改当前事件时,整个提要状态都被替换为该特定事件的新状态,因此如果用户返回到前一个事件,整个提要需要再次获取,同样是人减速器和时间表,这取决于事件.用户也有自己的个人资料提要,显示用户的提要项目.为了有这个提要,我会需要复制我在当前提要减速器中的内容,所以我认为有多个提要会更好,内部事件减少器.

But at the moment every time the user changes current event the whole feed state is replaced by a new state for that particular event, so if the user comes back to the previous event the whole feed needs to be fetched again, same is with people reducer and schedule, which depends on the event. Also user has it's own profile feed which shows user's feed items. And in order to have this feed I would need to duplicate what I have in the current feed reducer, so I thought it would be better to have multiple feeds, inside event reducer.

我想知道这样的状态结构会不会更好:

I was wondering if the state structure like this wouldn't be better:

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

然后我读了 redux#815redux#994 这不是嵌套减速器的最佳方式.它应该看起来或多或少像:

Then I read redux#815 or redux#994 that it's not the best way to nest reducers. Should it look more or less like:

{
  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: {...}
}

这种情况下的最佳实践是什么?哪种方式的性能最好?

What's the best practice in this case and which way is the most performant?

推荐答案

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

A normalized structure, like your last example, is definitely both a best practice and more performant. The state is flatter, so updates are more targeted and affect fewer unrelated objects; items can be easily looked up by ID as needed; and the update logic will generally be simpler. Also, this allows you to pass item IDs to connected child components, which then look up their own data based on that ID, and they will only need to re-render when their own data changes. Finally, it works well for caching data.

您可能想通读其中一些关于 Redux 性能了解更多信息,特别是高性能 Redux.您可能还想阅读 规范化状态和垃圾收集.

You might want to read through some of these articles on Redux performance for more information, particularly High Performance Redux. You may also want to read some of the discussion at Normalising state and garbage collection.

作为后续,我最近在 Redux 文档中添加了一个新部分,主题是 "结构化减速器".特别是,本节包括关于规范化状态形状"的章节和更新规范化数据".

As a follow-up, I recently added a new section to the Redux docs, on the topic of "Structuring Reducers". In particular, this section includes chapters on "Normalizing State Shape" and "Updating Normalized Data".

这篇关于减速器应该嵌套吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆