如何为具有列表/详细信息视图和分页的应用程序选择Redux状态形状？ [英] How to choose the Redux state shape for an app with list/detail views and pagination?

问题描述

想象一下，我的数据库中有很多条目（例如用户）。我还有两个路由，一个用于列表，另一个用于详细信息（您可以在其中编辑条目）。现在我正在努力解决如何处理数据结构问题。

Imagine I have a number of entries(say, users) in my database. I also have two routes, one for list, other for detail(where you can edit the entry). Now I'm struggling with how to approach the data structure.

我正在考虑两种方法和两种方法的组合。

I'm thinking of two approaches and a kinda combination of both.

• 我导航到 / list ，我的所有用户都是从存储在redux中的api下载的存储，在用户键下，我还添加了某种 users_offset 和 users_limit 只呈现部分列表


• 然后我导航到 / detail /< id> ，并使用< id> 存储 current_selected_user 作为val ...这意味着我将能够获得我的用户这样的数据 users.find（res => res.id === current_selected_user）


• 更新会很好也很容易，因为我只使用一个数据集和指向它的细节


• 添加新用户也很简单，再次只使用相同的用户列表

• I navigate to /list, all of my users are downloaded from api a stored in redux store, under the key users, I also add some sort of users_offset and users_limit to render only part of the of the list
• I then navigate to /detail/<id>, and store currently_selected_user with <id> as the val... which means I will be able to get my user's data with something like this users.find(res => res.id === currently_selected_user)
• updating will be nice and easy as well, since I'm working with just one data set and detail pointing to it
• adding a new user also easy, again just working with the same list of users

现在我用这种方法遇到的问题是，wh用户列表变得庞大（比如数百万），下载可能需要一段时间。而且，当我直接导航到 / detail /< id> 时，我还没有下载所有用户，所以要获取我的数据需要，我要先下载整件事。数百万用户只需编辑一个。

Now the problem I have with this approach is that, when the list of users gets huge(say millions), it might take a while to download. And also, when I navigate directly to /detail/<id>, I won't yet have all of my users downloaded, so to get data for just the one I need, I'm gonna have to first download the whole thing. Millions of users just to edit one.

• 我导航到 / list ，而不是从api下载我的所有用户，我只下载了几个，取决于我的 users_per_page 和 users_current_page 将被设置为，我可能会将数据存储为 users_currently_visible


• 然后我导航到 / detail /< id> ，使用<存储 curre_selected_user code>< id> 作为val ...而不是搜索 users_currently_visible 我只是从api下载用户的数据。


• 更新时，我不会以任何方式更新 users_currently_visible


• 也不会我在添加

• I navigate to /list, and instead of downloading all of my users from api, I only download a couple of them, depending on what my users_per_page and users_current_page would be set to, and I'd probably store the data as users_currently_visible
• I then navigate to /detail/<id>, store currently_selected_user with <id> as the val...and instead of searching through users_currently_visible I simply download user's data from api..
• on update, I'm not gonna update users_currently_visible in any way
• nor will I on add

我认为这里可能存在的问题是，我必须在访问时/ list ，再次从api下载数据，因为它可能与我的内容不同步在数据库中，我也可能不必要地详细下载用户数据，因为它们可能偶然已经在我的 users_currently_visible

What I see as possible problem here is that I'm gonna have to, upon visiting /list, download data from api again, because it might not be in sync with what's in the database, I also might be unnecessarily downloading users data in detail, because they might be incidentally already inside my users_currently_visible

• 我详细说明，我和分离数据集一样但不是直接从api下载用户的数据，我首先检查：
  
  
  
  
  • 我有 users_currently_visible
  
  
  • 如果是这样，是否有用户在我们之间使用我的ID？
    如果两者都是真的，我会将其用作我的用户数据，否则我会进行api调用
  
  
  • I detail, I do the same as in Separated data set but instead of directly downloading user's data from api, I first check:
    • do I have any users_currently_visible
    • if so, is there a user with my id between them? if both are true, I then use it as my user data, otherwise I make the api call

    这可能会奏效，但并不觉得这是正确的方法。我可能还需要在访问 / list 时下载 users_currently_visible 的新列表，因为我可能添加了一个新的一个..

    This would probably work, but doesn't really feel like it's the proper way. I would also probably still need to download fresh list of users_currently_visible upon visiting /list, because I might have added a new one..

    有没有粉丝喜欢这样做的方式？...我确信每一个redux用户都必须遇到同样的事情。

    Is there any fan favorite way of doing this?... I'm sure every single one redux user must have encountered the same things.

    谢谢！

    推荐答案

    请咨询真实世界示例。
    
    它显示了准确的解决方案这个问题。

    Please consult "real world" example from Redux repo.
    It shows the solution to exactly this problem.

    你的状态应如下所示：

    {
      entities: {
        users: {
          1: { id: 1, name: 'Dan' },
          42: { id: 42, name: 'Mary' }
        }
      },
      visibleUsers: {
        ids: [1, 42],
        isFetching: false,
        offset: 0
      }
    }
    

    注意我正在存储 e ntities （ID - >对象映射）和 visibleUsers （分别具有分页状态和ID的当前可见用户的描述）。

    Note I’m storing entities (ID -> Object maps) and visibleUsers (description of currently visible users with pagination state and IDs) separately.

    这与您的共享数据集方法类似。但是我不认为你列出的缺点是这种方法固有的真正问题。让我们来看看它们。

    This seems similar to your "Shared data set" approach. However I don’t think the drawbacks you list are real problems inherent to this approach. Let’s take a look at them.

    
    

    现在我用这种方法遇到的问题是当用户列表变得庞大时（比如数百万） ，下载可能需要一段时间

    Now the problem I have with this approach is that when then list of users gets huge(say millions), it might take a while to download

    您无需下载所有这些内容！将所有下载的实体合并到实体并不意味着您应该查询所有这些实体。 实体应包含已下载的所有实体到目前为止 - 不是世界上所有实体。相反，你只会根据分页信息下载你当前正在展示的那些。

    You don’t need to download all of them! Merging all downloaded entities to entities doesn’t mean you should query all of them. The entities should contain all entities that have been downloaded so far—not all entities in the world. Instead, you’d only download those you’re currently showing according to the pagination information.

    
    

    当我直接导航到/ detail /时，我还没有下载所有用户，所以为了获得这些用户的数据，我将不得不下载所有用户。数百万用户只需编辑一个。

    when I navigate directly to /detail/, I wouldn't yet have all of my users downloaded, so to get data for just the one, I'm gonna have to download them all. Millions of users just to edit one.

    不，你只需要其中一个。响应操作将触发，负责实体的reducer会将此单个实体合并到现有状态。仅仅因为 state.entities.users 可能包含多个用户并不意味着您需要下载所有这些用户。想想实体，而不是 要填充的缓存。

    No, you’d request just one of them. The response action would fire, and reducer responsible for entities would merge this single entity into the existing state. Just because state.entities.users may contain more than one user doesn’t mean you need to download all of them. Think of entities as of a cache that doesn’t have to be filled.

    最后，我将再次指导您到真实世界示例。它显示了如何为分页信息和实体缓存编写减速器，并如何使用<$在API响应中规范化JSON c $ c> normalizr ，以便Reducer可以轻松地以统一的方式从服务器操作中提取信息。

    Finally, I will direct you again to the "real world" example from Redux repo. It shows exactly how to write a reducer for pagination information and entity cache, and how to normalize JSON in your API responses with normalizr so that it’s easy for reducers to extract information from server actions in a uniform way.

    这篇关于如何为具有列表/详细信息视图和分页的应用程序选择Redux状态形状？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！