4

我们正在尝试forFeature为我们的应用采用一种模式。然而，多个特征是相关的。

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

例如考虑我们有以下实体

  • 产品
  • 供应商
  • 国家
  • 货币
  • 港口

在哪里作为模型

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

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

然后在product-detail页面中，我们显示产品的&currency以及country名称和country。supplier

考虑到我们还有一个supplier-details page显示上述供应商信息及其最近 10 种产品的地方。

当前处理所有这些的方式是使用这样的存储结构：

 - entities
 ---- product
 ---- supplier
 ---- currency
 ---- country
 ---- harbour
 - ui
 ---- other stuff ui related

这是通过根中的单个存储完成的。

然而，应用程序文件夹结构是这样划分的：

 - 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

正如您所看到的，文件夹结构有点杂乱无章，因为我还不确定该放在哪里harbour， 因为country其中currency一些是一般实体。

但是，我正在研究其中的forFeature一点，ngrx我想知道如果我们碰巧使用它以及功能是否可以一起使用，所有这些将如何组合在一起。

  • 这些实体中的每一个都是一个forFeature吗？
  • 还是应该将所有这些东西放在一个地方并具有一个entity功能，以便我的商店看起来与现在一样？
4

1 回答 1

3

forFeature旨在用于需要以惰性方式注册的 reducer，forChild与forRoot.

我认为这方面的经验法则是：

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

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

总而言之：

  • 你的实体结构对我来说似乎很好。
  • 我会将港口/国家/货币与您对文件结构的其他方式类似。
  • forFeature仅当该功能模块需要状态切片时才使用状态切片，并且该模块是lazy loaded.
于 2018-03-27T02:26:47.000 回答