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