Question

我们正在尝试为我们的应用采用forFeature模式。但是，多个功能是相关的。

我们有一个应用程序，其中同时显示多个实体关系。

例如，考虑我们有以下实体

产品
供应商
国家
货币
海港

模型

ìnterface Product {
  countryId: string;
  currencyId: string;
  supplierId: string;
}

interface Supplier {
  name: string;
  harbourId: string;
  countryId: string;
}

然后在product-detail页面中，我们会显示currency＆amp; country产品的country以及supplier的名称和supplier-details page。

考虑我们还有一个- entities ---- product ---- supplier ---- currency ---- country ---- harbour - ui ---- other stuff ui related，我们会在其中显示上述供应商信息以及最近10个产品。

当前处理所有这些的方式是使用商店结构：

 - features
 --- product
 ------ product.actions / product.reducer / product.effects / product.selector
 --- supplier
 ------ supplier.actions / supplier.reducer / supplier.effects / supplier.selector
 --- store 
 ------ reducers ( here we are importing all reducers to combine those)
 ------ harbour.actions / harbour.reducer / harbour.effects / harbour.selector
 ------ country.actions / country.reducer / country.effects / country.selector
 ------ currency.actions / currency.reducer / currency.effects / currency.selector

这是通过根目录下的单个商店完成的。

然而，app文件夹结构按如下划分：

harbour

正如您所看到的，文件夹结构有点混乱，因为我还不确定将country放在哪里，currency＆amp; forFeature因为其中一些是一般的实体。

然而，我正在查看ngrx的{{1}}位，我想知道如果我们碰巧使用它并且如果功能甚至可以一起使用，那么这一切将如何组合在一起。

这些实体中的每一个都是forFeature？
或者是否应将所有这些内容放在一个地方并具有entity功能，以便我的商店看起来与现在的相同？

Answer 1

与forFeature相比，

forChild用于需要以懒惰方式注册的减少符号forRoot。

我认为这样做的经验法则是：

如果仅对特定的延迟加载模块需要reducer，那么它应该是该模块的forFeature，因此只有在加载该模块后才会注册。

一旦需要在模块之间共享reducer（延迟加载或不加载），那么它需要在您的应用程序中处于更高的抽象级别，并且应该在启动时转到forRoot版本（全局可访问） “）

总结：

您的实体结构对我来说似乎没问题。
我会将港口/国家/货币与其他人的文件结构类似。
仅在forFeature中使用状态切片（如果该功能模块仅需要该切片，并且该模块为lazy loaded。

具有多个相关实体的ngrx`forFeature`

1 个答案: