我有一个应用程序，它使用同步API获取数据，并要求将所有数据存储在本地。数据集本身非常大，我不愿意将其存储在内存中，因为它可以包含数千条记录。由于我不认为实际的数据结构是相关的，我们假设我正在构建一个需要离线访问的电子邮件客户端，并且我希望我的存储机制是IndexedDB（异步）。
我知道一个简单的解决方案是不将数据结构作为状态对象的一部分，只使用所需的数据填充状态（例如，当触发email_OPEN操作时，将电子邮件内容存储在状态上）。这很简单，尤其是使用redux thunk。
然而，这意味着我需要折衷两件事：
- 用户数据不再是"应用程序状态"的一部分，尽管事实上是这样。由于同步行为很复杂，将其从应用程序状态机中删除会损害redux概念的优雅性（我理解它们的方式）
- 我真的很喜欢redux架构，希望我所有的逻辑都能通过它，而不仅仅是视图状态
关于如何使用非内存状态属性的redux，有什么最佳实践吗？我发现最难理解的是redux依赖于同步API，因此我无法用异步状态对象替换我的状态对象（除非我完全删除redux并用我自己的异步实现和连接器替换它）。
我在谷歌上找不到答案，但如果已经有关于这个主题的好资源，我也很想被指出。
更新：这个问题得到了回答，但我想更好地解释我是如何实现的，以防有人碰到它：
其主要思想是使用简单的redux reducers来维护客户端和服务器的更改列表，并使用连接器来侦听这些更改列表以更新IDB，还可以使用客户端更改来更新服务器：
- 当客户端进行更改时，请使用reducers更新客户端更改列表
- 当服务器发送更新时，请使用reducers更新服务器更改列表
- 连接器侦听存储，并在状态更改时更新IDB。还要维护已修改项目的内部列表
- 更新服务器时，使用修改项列表从IDB中提取delta并发送到服务器
- 访问数据时，使用正常操作从IDB中提取（例如使用redux thunk）
这种方法唯一需要注意的是，由于真实状态存储在IDB中，因此我们确实会丢失一个状态对象（以及更难倒带/快进的状态）的一些值
我认为你的第一个预感是正确的。如果（！）你不能把所有东西都储存在商店里，你就必须少在商店里储存。但我相信我可以让这个解决方案听起来更好：
IndexedDB只是成为另一个端点，就像您使用的任何服务器API一样。从服务器获取数据时，将其转发到IndexedDB，然后从中填充存储。商店只得到它需要的东西，只要它不太大或不过时，就把它缓存起来。
这真的和Facebook消费API没什么不同。商店中永远不会有用户的所有数据。引用是用ID实现的，并且在需要时加载这些ID。
你可以把所有的逻辑都保留在redux中。只需像往常一样为用户操作和数据更改创建操作，获取所需的数据并进行处理。界面仍然完全由用户数据定义，因为在需要时，存储中总是有获取其余数据所需的信息。它只是有点精简，也就是说，在用户导航到邮箱之前，只保存邮件总数或邮箱ID