关于前端:使用-Angular-14-的-inject-函数优化对-Ngrx-的使用方式

咱们先看 Angular 里一个惯例的应用 Ngrx Store 的例子：

下面这段代码的缺点是，Component 作为 UI 的展示层，间接依赖于作为第三方库的 Store API —— 一个合乎逻辑的措施是，将这个逻辑通过 facade 服务的思路，抽取到一个 service 中，以爱护 Component 免受库弃用或破坏性更改 (breaking changes) 的影响。

在 Angular 14 之前，咱们能够将下面的代码进行重构，把 Store 相干的操作，封装到一个 facade service 里：

尽管重构之后代码行数变多了，然而这种设计对 breaking changes 可能应答自若，因为咱们当初只须要在一个中央治理代码，即 EntityFacade，而不是重构之前在 Component 里应用 Store 的任何中央。

当初让咱们看看 inject() 形式。

有一种观点认为，应用闭包须要将返回的函数存储在 Component 的属性中，这减少了 Component 的复杂性，还不如应用构造函数注入和服务。

到底应用 inject 还是传统的构造函数注入形式，取决于团队制订的编程标准。