我正在使用 ngrx 存储来维护应用程序状态,使用 normalizr 将我的数据从 API 调用和 Immutable 中展平。到目前为止,它运行得非常好,但我正在处理一些更复杂的数据关系,我想知道如何继续构建存储。
为了简化事情,我有两组对象。 session 和发票。
一位用户登录并可以查看他的 session 列表。 store 中的状态保存在一个对象中 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;
}
(实体包含规范化输出 - 客户和导师是 session 中包含的嵌套类型)
这真的很好用。 reducer 将其设置为加载,以便 View 可以显示加载条,然后填充数据我可以在一个合理的平面方式中使用它,引用映射数据中的 id。
他们可以加载发票,这与
IInvoices
非常相似。目的: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;
}
所以我的商店看起来像这样:
export interface IAppState {
sessions: ISessions;
invoices: IInvoices;
}
然而,现在我来到了更复杂的关系。 session 被分配到发票。有几种前进的方式:
例如:
export interface IAppState {
sessions: ISessions;
invoices: IInvoices;
invoicesSessions: Map<number, ISessions>;
}
还有一个问题是我是否应该存储两个单独的客户和导师列表,一个在 ISessions 中,另一个在 IInvoices 中。像这样拆分商店是个坏主意吗?这意味着我的 reducer 必须在整个
IAppState
上运行。对象而不是子部分。基本上:当我输入数据时,我是否应该将其剥离并编译大的 ID 索引列表,让 View 几乎“查询”他们需要的东西 - 基本上像数据库一样使用存储,或者我应该持有一个深层嵌套直接反射(reflect) View 的对象集合 - 意味着数据经常在需要的地方重复多次?
最佳答案
是的,推荐的构建 Redux 存储的方法是根据您的数据而不是您的 View 来构建状态形状,而对关系数据的建议是保持所有规范化。使用选择器函数作为对该状态的查询。
有关更多信息,请参阅:
还有,我的 "Practical Redux" tutorial series展示了如何使用 Redux-ORM 库来管理 Redux 状态中的关系数据:Practical Redux-ORM Basics和 Practical Redux, Part 2: Redux-ORM Concepts and Techniques .
关于redux - 构建状态管理存储(ngrx/redux)。平面代表数据,还是嵌套代 TableView ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42472415/