angular - Redux - 如何在大型应用程序中组织商店

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

去年关闭。




Improve this question




我们正在结合 NGRX 使用 Angular 7 开发 SPA。几个月前我们已经迁移到 NGRX，主要用于身份验证和 session 数据。在那之后，我们也开始移动其他功能。我将描述问题以及我们头脑中的解决方案及其缺点。听到您如何解决此问题(如果您有)或有关如何解决问题的想法，我将非常感激。

使用 Redux(NGRX) 的动机

我们有需要在多个组件之间共享的数据。由于我们的组件由 Angular 路由器分隔，因此无法通过属性共享。

通过重用加载的数据(如 Auth/Session)来减少请求数量

性能 - 当组件使用 ChangeDetectionStrategy.OnPush 时，Angular 的执行速度要快得多

业务问题

在我们的应用程序中，我们有 6 个模块。每个模块至少有 10 个功能(页面)。他们之间只有一些共同的细节。

使用 Redux Store 的第一步

由于我们的主要问题是 #1 和 #2(如上所述)，我们从以下存储结构开始:

 {
  "authentication": {
    "isLoading": false,
    "error": {},
    "token": "auth-token"
  },
  "session": {
    "userDetailsIsLoading": false,
    "userDetailsData": {},
    "userDetailsError": {}
  }
}

到现在为止还挺好。它就像所有带有增加/减少/重置计数器的 Redux 教程一样。

迁移模块功能

有趣的事情开始了，因为我们在应用程序中有很多功能(6 个模块 * 10 个功能 = 60+)。
第一个决定是使用 reducer per feature而不是 reducer per entity因为我们的页面具有相同类型的实体，但使用不同的过滤器获取。我们在服务器端过滤数据，因为数据量很大。
例如:最近 10 个帖子，前 10 个帖子 - 都在同一页面上

所以，我们用更多的 reducer 扩展了我们的商店:

{
   "authentication": {},
   "session": {},
   "blogs-list": {},
   "blogs-add": {},
   "administration-users": {},
   "administration-add-user": {}
}

问题

Action 类型碰撞

是的，我们在使用格式 [Feature] Action Description 时遇到了第一类冲突。 .
为了解决这个问题，我们决定添加使用命名空间 [Module][Feature] Action Description .

大店

这是最大的问题。整个商店变得非常大。 store 干净的时候不是问题，但是经过几次导航后，store 中包含了很多不需要的数据。

我们考虑的解决方案

延迟加载

Angular 允许延迟加载所谓的 NGRX Features .这意味着我们可以从共享数据(auth、session)开始，一旦打开一个模块，所有的 reducer 都会被添加到存储中。该解决方案部分解决了该问题。如果您导航到所有模块，商店会再次变大。

切换到实体 reducer

这在理论上看起来很容易，但在实践中很难。正如我提到的，我们有一种仪表板，我们在其中显示相同的实体，但使用不同的过滤器 + 分页来获取。在头脑中，我有一个想法为这些情况使用不同的 reducer ，例如:

{
   "latest-entities": {
       "isLoading": bool,
       "data": {},
       "error": {},
   }, 
   "most-popular-entities": {
       "isLoading": bool,
       "data": {},
       "error": {},
   }
}

但我们还有另一个缺点。我们曾经将过滤器保存在特征存储中，一旦我们更改过滤器，效果就会触发数据重新加载。切换到此架构后，我们将数据重新加载的责任转移到 containers . Container将负责分派(dispatch)行动到两个商店 latest-entities和 most-popular-entities .这个解决方案也会越来越大。重新组织 reducers 和 store 并不能完全解决这个问题。

不要将功能移动到 Redux，而是将它们保存在容器中

我们可以在 containers 中保留特征逻辑并且仅将 redux 用于跨模块数据，例如 session 、身份验证和通知。这也是一种解决方案，但有其缺点。我想保持应用程序的一致性，并且不要在容器和商店中都有业务逻辑。

重置商店

为了保持 store 更小，我们可以创建一个 action，将 store 重置为初始状态，一旦不使用该功能就会调度该状态。下面是一个例子:

  public ngOnDestroy(): void {
    this.store$.dispatch(new BlogStoreActions.DestroyAction());
  }

Answer 1

我还不能发表评论，但你的问题让我很好奇，所以我把它提交给了 twitter 和 ngrx 维护者之一。

这是回应(来自 Wes Grimes):

If the store gets too big then maybe it’s time to reconsider what data is fetched client side. Do you really the full data model or would a paired down view model suffice? Fetch data in batches bits at a time. Get 50 and then go back for 50 more as you need it (lazy load).

Also take advantage of lazy loaded feature modules in angular and use the forFeature with NgRx and then only load the portion of the store needed. But again. If size is a concern, consider minimizing client side data and offload the heavy lifting to the backend.

关联:

https://twitter.com/qkwrv/status/1217593781282734080