11

我有一个离线 React Web 应用程序，其中所有数据都本地存储在 indexedDB 中。除了静态资产的文件托管之外，没有其他服务器。我已经到了现在开始考虑使用 redux 的地步，但我试图了解将更多数据移动到存储和继续依赖数据库之间的权衡。将本地数据库与 redux 一起使用的惯用方式是什么？

目前我的应用程序由几个容器组件组成，每个容器组件都从componentWillMount. 集成 redux 的一种选择是保持基本相同，唯一的区别是状态保存在存储中，数据是使用操作和 thunk 获取的。

或者，我看到很多示例代码在启动时将所有数据加载到存储中。这使得整个应用程序更具确定性，更易于测试和重现。主要组件之间的切换会立即发生（以初始应用程序加载为代价）。但是我失去了数据库提供的好处，比如索引和漂亮的查询。

从字面上看，将整个数据库加载到存储中似乎是不合理的，至少在我的情况下，这将是大约 10MB 的数据，也许更多。所以我总是至少有一些组件需要在挂载时继续获取它们的数据。但是有一个数据子集是应用程序的核心，可以说应该完整地加载表（这可能是大约 5,000 到 10,000 个对象）。

使用本地存储和 redux 的惯用方式是什么？componentWillMount我觉得如果可以避免异步获取，则它不是惯用的。即使在状态小到可以完全加载到存储中的情况下，是否值得放弃良好高效的查询接口的好处？

编辑：我应该提一下：我正在使用Dexie，这是一个非常非常棒的用于处理 indexedDB 的库。它速度快，有一个很好的查询界面，处理迁移等......我真的很想继续使用 Dexie，除非有非常充分的理由不这样做。

作为参考，这里是Dexie 的 github 上关于这个主题的讨论。一般的外卖形式是“视情况而定”。不是我一直在寻找的答案，所以如果可能的话，我希望能获得更多的见解。

4

2 回答 2

9

用我到目前为止所发现的来回答这个问题。如果我有更好的答案，我很乐意将其标记为已接受。

TL;DR：这确实取决于。做事情的惯用方式确实是在有意义的情况下尽可能多地投入状态。但是，在有意义的情况下从其他地方异步获取数据并不是不习惯的。否则，许多应用程序将根本不切实际。

Dan Abramov 的蛋头教程（甚至标题为“使用Idiomatic Redux构建 React 应用程序”）采用了将所有状态保存在存储中并定期将其作为一个巨大的 blob（或相关切片）持久化的方法。

这样做的好处是您可以像往常一样使用 redux 存储，并且持久性本质上是透明的。如果您的数据足够小，这不是问题，那就太好了。

正如@seanyesmunt 所指出的，有redux-persist，它基本上做了一个更复杂的版本。

当然，不久之后，他重写了教程以从 API 获取数据。此时您可以假装 API 是 IndexedDB，实际上并没有什么不同。由于整体上没有完全确定的状态，你失去了 redux 的一些好处，但在许多情况下你别无选择。

我最终做了与Dexie 的 Redux 示例代码基本相同的事情。基本上，使用 thunk 在某些操作上异步写入数据库。

于 2017-07-17T18:05:08.940 回答
5

编辑 2020-12-18：我建议使用dexie-react-hooks和useLiveQuery()挂钩。与它一起工作是一种了不起的体验，消除了这方面的所有复杂性。另请参阅此博客文章。

我的旧答案是：这个问题对我很感兴趣，并且我一直在用 react 和 dexie 详细说明我参与的最后一个项目。我个人正在研究 graphql 如何解决这种情况，但我仍在学习. 希望提供一个graphql/dexie的例子。据我了解，graphql 将充当服务层，其“模式”（后端存储）将使用所需的 dexie 查询来产生更扁平化和简单化的 graphql 数据要求。我会从 Apollo 或 Facebook 寻找一些现成的 grapql 示例来开始使用，我相信它会很容易使用。我通常不认为它可以扩展以将整个数据库读入内存。而且我相信应用程序启动对最终用户至关重要，所以我真的希望为此找到一个完美的架构。目前我的希望是 Graphql。

于 2017-07-07T06:36:19.583 回答