构建状态管理存储(ngrx/redux).平面代表数据，还是嵌套代表视图? [英] Structuring state management store (ngrx/redux). Flat as representative of data, or nested as representative of view?
问题描述
我正在使用 ngrx 存储来维护应用程序状态，使用 normalizr 将我的数据从 API 调用和 Immutable 中展平.到目前为止，它运行得非常好，但我正在处理一些更复杂的数据关系，我想知道如何继续构建商店.
I'm using ngrx store, to maintain application state, normalizr to flatten my data from API calls and Immutable. So far it's been working really well, but I'm getting to some more complex data relationships and I was wondering how to proceed with structuring the store.
为了简化事情，我有两组对象.会话和发票.
To simplify things, I have two sets of objects. Sessions, and Invoices.
一个用户登录并可以查看他的会话列表.存储中的状态保存在对象 ISessions 中:
One user logs on and can view his list of Sessions. The state in the store is held in an object ISessions:
export interface ISessions extends Map<String, any> {
result: List<Number>;
entities: {
sessions: Map<Number, ISessions>,
clients: Map<Number, IClient>,
tutors: Map<Number, IProfile>
},
adding: boolean;
loading: boolean;
loadingFailed: boolean;
error: string;
}
(实体包含规范化输出 - 客户和导师是会话中包含的嵌套类型)
(entities contain the normalized output - clients and tutors are the nested types contained in sessions)
这真的很好用.减速器将其设置为加载，以便视图可以显示加载条，然后填充数据我可以在合理的平面方式中使用它，引用映射数据中的 id.
This works really well. The reducer sets it to loading so the view can display loading bars, then the data is populated I can use it in a sensible flat mannor referencing id's in the mapped data.
他们可以加载发票，这与 IInvoices 对象非常相似:
They can load invoices, this works very similarly around an IInvoices object:
export interface IInvoices extends Map<String, any> {
result: List<Number>;
entities: {
invoices: Map<Number, IInvoice>,
clients: Map<Number, IClient>,
tutors: Map<Number, IProfile>
},
adding: boolean;
loading: boolean;
}
所以我的商店看起来像这样:
So my store looks like this:
export interface IAppState {
sessions: ISessions;
invoices: IInvoices;
}
然而，现在我来到了更复杂的关系.会话被分配到发票.有几种方法可以前进:
However, now I've come to the more complex relationship. The Sessions are assigned to Invoices. There's a few ways of going forward:
每个发票本身都可以有一个 ISessions 对象.这似乎与数据结构扁平化的想法背道而驰.我也可能有重复的会话，存储在 AppState.sessions 和 AppState.invoices 中.然而，管理起来会更容易，因为 IInvoice 更直接地映射到视图的状态(加载会话等存储在所有封装的发票 ISessions 对象中).
Each of the Invoices could themselves have an ISessions object. This seems to go against the idea of having the data structure flat. I'd also likely have repeat sessions, stored in the AppState.sessions and the AppState.invoices. However it would be easier to manage as the IInvoice more directly maps to the state of the view (loading the sessions etc is stored in the invoices ISessions object all encapsulated).
我可以将 ISessions 映射到商店中的发票 ID 与 ISessions 和发票分开存储:
I could store a map of ISessions to invoice IDs in a the store separately to the ISessions and invoices:
例如:
export interface IAppState {
sessions: ISessions;
invoices: IInvoices;
invoicesSessions: Map<number, ISessions>;
}
- 我可以将发票加载到现有的 ISessions 对象中.这意味着所有会话数据都在同一个地方，并且没有重复.一个问题是我现在很难将它映射到视图.每张发票都必须获取会话列表并仅筛选出它需要的内容.我必须开始跟踪 ISessions 对象中发票会话的加载.
还有一个问题是，我是否应该存储两个单独的客户和导师列表，一个在 ISessions 中，另一个在 IInvoices 中.像这样拆分商店是个坏主意吗?这意味着我的 reducer 必须全部操作整个 IAppState 对象，而不是子部分.
There's also the question of whether I should be storing two separate lists of clients and tutors, one in ISessions and one in IInvoices. Is splitting the store like this a bad idea? This would mean my reducers would have to all operate on the whole IAppState object rather than the sub-sections.
基本上:当我获取数据时，我是否应该将其剥离并编译大的 ID 索引列表，让视图几乎查询"他们需要的东西 - 基本上像数据库一样使用存储，或者我应该持有一个直接反映视图的深层嵌套对象集合 - 意味着数据经常在需要的地方重复多次?
Basically: When I get data in, should I be stripping it out and compiling big ID-indexed lists, letting the view's then almost 'query' what they need - basically using the store like a database OR should I be holding a deep-nested collection of objects that directly reflect views - meaning data is often repeated where it's needed multiple times?
推荐答案
是的，推荐的构建 Redux 存储的方法是根据数据而不是视图来构建状态形状，而对于关系数据的建议是保持一切正常化.使用选择器函数作为对该状态的查询.
Yes, the recommended approach for structuring your Redux store is to build your state shape in terms of your data, not your views, and the recommendation for relational data is to keep it all normalized. Use selector functions to act as queries into that state.
有关详细信息，请参阅:
For more info, see:
此外，我的Practical Redux"教程系列展示了如何使用 Redux-用于管理 Redux 状态中的关系数据的 ORM 库:实用 Redux-ORM 基础 和 实用 Redux，第 2 部分:Redux-ORM 概念和技术.
Also, my "Practical Redux" tutorial series shows how to use the Redux-ORM library to manage relational data in your Redux state: Practical Redux-ORM Basics and Practical Redux, Part 2: Redux-ORM Concepts and Techniques.
这篇关于构建状态管理存储(ngrx/redux).平面代表数据，还是嵌套代表视图?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
