共计 928 个字符，预计需要花费 3 分钟才能阅读完成。
Angular 组件架构能够通过充分利用 Angular（@Input() 和 @Output()）和 ngrx/store（dispatch() 和 select() 办法）的外在个性来使 Angular 应用程序受害。
上图的体系架构里，咱们察看到了两种类型的 Component：
- Smart(有时也称为 Container)
- Dummy(有时也称为 Presentational)
Container 组件是惟一晓得 Store 存在的组件。ngrx/store 模块的外在个性促成了该组件和 Store 之间的通信。
- 该组件通过 select() 办法订阅 Store 以接管申请的数据流
- 该组件通过 dispatch() 办法向 Store 分派一个动作，以表明须要更新状态。
上面是 SAP 电商云 Spartacus UI 里一个典型的 container Component 例子：
只管容器组件晓得 Store 并间接与 Store 通信，但展现组件并不知道 Store。它只是应用 Angular 的外在个性与容器组件进行通信。容器组件在与 Store 通信时充当两者之间的中间人。容器组件和展现组件之间的任何交互都会以这种形式过滤到 Store。
这就是展现组件和容器组件之间的通信形式：
- presentational 组件定义了 @Input() 参数，以通过容器组件对 Store 的订阅接管来自状态的任何数据切片。容器组件负责提供展现组件所需的适当数据。请记住，那些 @Input() 参数是不可变对象！
- presentational 组件应用 @Output() 事件发射器来申请应用程序状态的任何更新。容器组件解决 presentational 组件的事件，而 presentational 组件又间接向 Store 分派一个动作。
从以上阐述能够分明地看到每种组件的责任辨别。只管展现组件仅应用 Angular 固有个性来出现任何 HTML，但容器组件齐全依赖于 ngrx/store 模块固有个性。
通过应用这种模式，关注点拆散 (seperation of concern) 的设计思维得以体现。应用程序中只有一层组件晓得 Store，其余的即示意组件的构建块，齐全感知不到 Store 层的存在。这种设计模式促成了将 Angular 应用程序组合成小型、简洁和繁多职责的示意组件汇合来构建。