angular - 子组件的 NGRX 和状态管理

Question

目前正在重构 Angular 应用程序以使用 ngrx 存储并有两个选项。这是我们应用程序的基本结构。我相信大多数 Angular 应用程序都是以相同的方式构建的:

AppComponent
|-- ContainerComponent
    |-- ChildComponent1
    |   |-- GrandChildComponent
    |       |-- GrandGrandChildComponent
    |-- ChildComponent2

ContainerComponent 已注入(inject) Store<AppState> .我要解决的问题是 GrandGrandChildComponent(比如 DropDownMenu 组件)必须根据应用程序的状态更改其行为(即在商店中发生的某些情况下禁用某些菜单项)并在单击时发出事件在菜单项上所以 ContainerComponent (或任何其他组件，不必要的祖先)可以对其使用react。

有两种解决方法:

1. 使用 @Input 在组件之间进行通信/@Output
2. 注入(inject) Store进入任何需要了解状态的组件

选项 1 是我在文档中读到的最常见/推荐的模式。所以只有 ContainerComponent 是胖的，所有的 child 都是瘦/笨的，并且依赖于通过 @Input 进入的状态。 .

但据我所知，这种方法增加了很多样板，您必须在其中添加不必要的属性，只是为了将状态传递给 GrandChild 组件。而且它也打破了关注点分离原则，因为任何中间组件都必须知道下面的组件需要什么。如果知道仅在 Grand Components 上可用的详细信息，则制作通用组件并不容易。

另一方面，方法 2 似乎解决了分离关注点的问题，而且它的实现似乎也更简洁。但由于我在使用 redux 方面相对较新我不确定这是否是要走的路，也许我不知道在重构太深入时可能会遇到的任何陷阱。

IMO，这两种方法都提供了一种测试每个组件的简单方法，这对我来说意义重大。

我不确定该采用哪种方法。我应该注意哪些陷阱？

谢谢

Answer 1

以下是 redux 的创建者 Dan Abramov(ngrx 的灵感来自 redux，因此很多相同的想法都适用于 ngrx)就此主题所说的话:

When to Introduce Containers? I suggest you to start building your app with just presentational components first. Eventually you’ll realize that you are passing too many props down the intermediate components. When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data, it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree. This is an ongoing process of refactoring so don’t try to get it right the first time. As you experiment with this pattern, you will develop an intuitive sense for when it’s time to extract some containers, just like you know when it’s time to extract a function.

来源: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#7dc5