vop*_*lif 9 reactjs dexie redux
我有一个离线的React Web应用程序,其中所有数据都本地存储在indexedDB中.除了托管静态资产的文件之外,没有其他服务器.我现在开始考虑使用redux,但我正在努力理解将更多数据移入商店并继续依赖数据库之间的权衡.使用带有redux的本地数据库的惯用方法是什么？
目前我的应用程序由几个容器组件组成,每个容器组件都从db中获取数据componentWillMount.集成redux的一个选项是保持这个大致相同,唯一的区别是状态保存在存储中,数据是使用动作和thunk获取的.
或者,我已经看到很多示例代码在启动时将所有数据加载到商店中.这使整个应用程序更具确定性,更易于测试和重现.主要组件之间的切换将立即发生(以初始应用程序负载为代价).但我失去了DB提供的好处,如索引和好查询.
看起来像是不合理地将整个数据库加载到商店中,至少在我的情况下,这将是大约10MB的数据,可能更多.所以我将至少有一些组件需要继续在mount上获取数据.但是有一个数据的子集是应用程序的核心,并且可以认为表应该完整地加载(这可能是大约5,000到10,000个对象).
使用本地存储和redux的惯用方法是什么？我觉得componentWillMount如果可以避免异步提取不是惯用的.即使在状态足够小以至于可以完全加载到商店的情况下,是否值得放弃高效查询界面的好处？
编辑:我应该提一下:我正在使用Dexie,这是一个非常非常好的库,用于处理indexedDB.它很快,有一个很好的查询界面,处理迁移等...我真的想继续使用Dexie,除非有一个非常强烈的理由不这样做.
作为参考,这里是关于Dexie的github的这个主题的讨论.一般的拿走形式是"它取决于".不是我想要的答案,所以我希望在可能的情况下获得更多的洞察力.
用我迄今发现的东西自己回答这个问题.如果我更好地回答,我会很乐意将其标记为已接受.
TL; DR:它确实依赖.做事的惯用方法确实只要有意义就可以放在状态中.但是,在有意义的情况下从其他地方异步获取数据并不是不恰当的.否则许多应用程序将是不切实际的.
Dan Abramov的egghead教程(甚至标题为"使用惯用 Redux 建立反应应用程序")采用的方法是在商店中拥有所有状态并定期将其保持为一个巨大的blob(或相关切片).
这样做的好处是您可以像往常一样使用redux存储,并且持久性基本上是透明的.如果您的数据足够小,这不是一个问题,这很好.
正如@seanyesmunt所指出的,还有redux-persist,它基本上是一个更复杂的版本.
当然,在那之后不久,他重写了教程以从API获取数据.此时你可以假装API是IndexedDB,它实际上并没有什么不同.由于没有完全确定的状态整体,你失去了redux的一些好处,但在许多情况下你别无选择.
我最终做的与Dexie的Redux示例代码基本相同.基本上,使用thunks在某些操作上异步写入DB.
编辑 2020-12-18：我建议使用dexie-react-hooks和useLiveQuery()挂钩。这是一次令人惊奇的工作体验，消除了与此相关的所有复杂性。另请参阅这篇关于它的博客文章。
我以前的答案是：这个问题对我来说很感兴趣，并且我在我参与的上一个项目中一直在详细阐述 React 和 Dexie。我个人正在研究 graphql 如何解决这种情况，但我仍在学习。我希望提供一个 graphql/dexie 的例子。据我了解，graphql 将充当服务层，其“架构”（后端存储）将使用所需的 dexie 查询来生成更扁平、更简单的 graphql 数据需求。我将查看来自 Apollo 或 Facebook 的一些现成的 grapql 示例来开始使用，我相信它会很容易使用。我通常不认为它可以扩展以将整个数据库读入内存。我相信应用程序启动对于最终用户至关重要，因此我真的希望为此找到一个完美的架构。目前我的希望寄托在 Graphql 上。
| 归档时间： |
|
| 查看次数： |
1896 次 |
| 最近记录： |