问题描述
因此，我们计划使用带有 React+Redux 前端服务器的 PHP 后端.我们正在开发一个非常大的应用程序，整个应用程序中有很多表.由于它将是一个单页应用程序，所有数据都包含在存储对象中.
So, we are planning to use a PHP backend with a React+Redux frontend server. We are developing a very large application, lots of tables across the entire application. Since it will be a Single Page Application, all the data is contained within on store object.
那么，让我们看看我的心态是否正确.当我登录应用程序时，我的状态几乎是空的.当我访问页面时，我的状态将开始填满.示例:我访问应用程序的照片"，然后我最终会从我的数据库中加载一些照片并将其放入我的商店:
So, let's see if I am with the right mindset. My state would start almost empty when I login into the app. As I visit pages, my state will start to fill up. Example: I visit the "photos" of the app, then I will end up load some of the photos from my DB and putting it inside my store:
state{
...
photos: [1: {...}, 3: {...}, 17:{...}]
...
}
然后，如果我需要 id = 17 的照片，我不需要再次请求它，我可以在我的商店中使用它，对吗?或者我可能先从商店拿它并请求它异步以检查它是否有变化.
And later on, if I need photo with id = 17, I don`t need to request it again, I can use it from my store, right? Or maybe I take it from store first and request it async to check if there were changes to it.
随着我访问越来越多的页面，我将拥有一个巨大的 store 对象，其中包含来自不同表格的许多元素，例如.照片、视频、user_configurations、朋友等.我应该如何处理数据一致性?如果我需要一个 10 分钟前已经获取的对象，我应该再次请求它吗?拥有这么大的 store 对象是否健康"?
As I visit more and more pages, I'll have a huge store object with a lot of elements from different tables, eg. photos, videos, user_configurations, friends etc. How should I deal with data consistency? If I need an object I already fetched 10min ago, should I request it again? Is it "healthy" to have such a big store object?
我打算使用 normalizr &重新选择以在 react-redux 中操作我的日期.
I'm planning to use normalizr & reselect to manipulate my date inside react-redux.
有什么想法吗?我想听听您认为如何处理这种情况的好方法.
Any thoughts on it? I would like to hear how do you think is a good way to deal with the situation.
提前致谢！
法比奥
推荐答案
是的，标准化的 Redux 存储是标准建议.请参阅 Redux 常见问题:组织嵌套状态，构建Reducers - 规范化状态形状，以及选择器和规范化 我的 React 的一部分/Redux 链接列表以获取更多信息.
Yes, a normalized Redux store is the standard recommendation. See Redux FAQ: Organizing Nested State , Structuring Reducers - Normalizing State Shape, and the Selectors and Normalization part of my React/Redux links list for more information.
至于缓存数据，从概念上讲，这应该与任何其他客户端设置没有什么不同.无论您使用的是 Redux、Angular、Ember、Backbone 还是其他东西，存储大量数据都会占用类似的内存量.您可以自行决定要缓存多少，以及何时以及如何清除缓存数据.
As for caching data, conceptually this shouldn't really be different than any other client-side setup. Storing lots of data will take up a similar amount of memory, no matter whether you're using Redux, Angular, Ember, Backbone, or something else. It's up to you to decide how much you want to cache, and when and how you might want to clean out cached data.
最后，为了操作 Redux 存储中的关系/规范化数据，我推荐一个名为 Redux-ORM 的库.一般来说，您绝对应该使用 Reselect，Normalizr 非常适合对您收到的数据进行规范化，但 Redux-ORM 提供了一个有用的抽象层，用于查询和更新存储中的规范化数据.我写了几篇博客文章描述了它的用法:Redux-ORM 基础 和 Redux-ORM 概念和技术.
Finally, for manipulating relational/normalized data in your Redux store, I recommend a library called Redux-ORM. You should absolutely use Reselect in general, and Normalizr is good for normalizing data you've received, but Redux-ORM provides a useful abstraction layer for querying and updating that normalized data once it's in the store. I've written a couple blog posts describing its use: Redux-ORM Basics and Redux-ORM Concepts and Techniques.
这篇关于在 React + Redux SPA SaaS 中处理大型存储中的数据一致性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！