如何为具有列表/详细信息视图和分页的应用程序selectRedux状态形状？

想象一下，我的数据库中有很多条目（比如用户）。我也有两条路线，一条是列表，另一条是细节（在哪里可以编辑条目）。现在我正在努力如何处理数据结构。

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

共享数据集

我导航到/list ，我所有的用户都是从api下载的，存储在redux存储中，在关键users ，我还添加了一些users_offset和users_limit来只呈现列表的一部分
然后我导航到/detail/<id> ，并存储与<id>作为val …这意味着我将能够得到我的用户数据像这样users.find(res => res.id === currently_selected_user)
因为我正在处理一个数据集和指向它的详细信息，所以更新也会很好，也很容易
添加一个新的用户也很容易，再次只是与相同的用户列表

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

我导航到/list ，而不是从api下载所有的用户，我只下载其中的几个，这取决于我的users_per_page和users_current_page将被设置为，我可能将数据存储为users_currently_visible
然后导航到/detail/<id> ，将/detail/<id>存储为users_currently_visible作为val …，而不是通过users_currently_visible进行search，只需从api下载用户的数据。
在更新，我不会以任何方式更新users_currently_visible
我也不会加上

我所看到的可能的问题是我必须在访问/list再次从api下载数据，因为它可能与数据库中的数据不同步，我也可能不必要地下载用户数据，因为他们可能已经在我的users_currently_visible

我详细说明，我在分离的数据集中做同样的事情，但不是直接从api下载用户的数据，我首先检查：
- 我有任何users_currently_visible
- 如果是这样，有一个用户与我之间的身份证？如果两者都是真实的，那么我将其用作我的用户数据，否则我会进行api调用
同样发生在更新，我检查如果我的用户存在users_currently_visible如果是这样，我也更新该列表，如果不是我什么都不做

这可能会起作用，但并不真的觉得这是正确的方式。我也可能还需要下载访问/list users_currently_visible新鲜/list ，因为我可能已经添加了一个新的..

是否有任何粉丝喜欢这样做的方式？我敢肯定，每个用户都必须遇到同样的事情。

谢谢！

请参阅Redux回购“真实世界”的例子。
它显示了这个问题的解决scheme。

你的状态应该是这样的：

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

注意我分别存储entities （ID – >对象映射）和visibleUsers （描述当前可见用户的分页状态和ID）。

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

现在我用这种方法的问题是，当用户名单变得巨大（比如说数百万）时，下载可能需要一段时间

你不需要全部下载！将所有下载的实体合并到entities并不意味着您应该查询所有这些entities 。 entities应该包含迄今为止已经下载的所有实体 – 不是世界上所有的实体。相反，您只能根据分页信息下载当前显示的内容。

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

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

最后，我会再次引导你回到Redux回购的“真实世界”例子。它显示了如何为分页信息和实体caching编写reducer，以及如何使用normalizr对API响应中的JSON进行normalizr以便Reducer可以轻松地以统一的方式从服务器操作中提取信息。