typescript - Angular2 @Inputs 应该公开还是我们可以/应该通过将它们设为私有(private)来拥有更严格的 API？

Question

我正在使用 Angular2 和 Typescript

假设我的应用组件模板中有以下内容:

... 
<coffee-cup [coffee]=""
...

我的 coffee-cup 组件:

@Component({
  selector: 'coffee-cup',
  ...
})
export class CoffeeCup {

  @Input() 
  public coffee = 0;

}

我目前不确定我的输入应该是什么样子。它可能看起来像这样:

@Input()
public coffee = 0;

或者

@Input()
private coffee = 0;

我目前倾向于将成员变量 coffee 设为私有(private)。

• 我想为组件定义一个明确的公共(public)API
• 我只想公开通过模板设置 coffee 属性
• 我目前没有任何理由允许直接从父组件读取或设置咖啡。如果需要，我可以删除 private 修饰符。

我查看组件的方式是有两个独立的 API 可以与之交互:

1. 模板 API，由 @Inputs 和 @Outputs 组成
2. 包含所有公共(public)属性和方法的 Typescript API

我没有检查过以下情况会发生什么，但是，它可能会改变答案:

• 假设咖啡成员(member)是公开的。如果我的 appComponent 使用 @ViewChild 访问 CoffeeCup 并设置咖啡成员，生命周期 Hook (如 ngOnChange) 火？

重申一下这个问题:Angular2 @Input 应该公开还是我们可以/应该通过将它们设为私有(private)来拥有更严格的 API？

Answer 1

首先，从API设计的 Angular 来看，@Input隐含public。从 Angular 来看也是如此，这些装饰器描述了与组件交互的界面。

angular 使用 @Input 装饰器或任何其他元装饰器，让 angular 了解您的意图并更好地理解模板及其与组件类的关系。

在某些情况下，变更检测引擎也使用它。例如，@Input 是变化检测跟踪的字段，它向 CD 引擎提示应该监视该属性。

拥有带有 @Input 装饰器的私有(private)属性在运行时不应该有任何影响。这个修饰符是虚拟的，它在 TypeScript 到 JavaScript 编译之后消失了。

但是，根据您的环境，可能会出现一些影响:

通常，拥有 TypeScript 和元数据的一大好处是拥有智能 IDE，这意味着 IDE 可以在您编码时为您提供帮助。拥有私有(private)属性(property)可能会或可能不会影响，这取决于每个 IDE 的实现。在属性上使用 @Input 会导致 IDE 在您为该组件编写 HTML 标记时在智能感知窗口中显示该属性。

另一个风险因素是 future 对 typescript 中缩小/丑化的支持。私有(private)属性，顾名思义，在类内部没有其他地方使用。这个特性意味着编译器可以更改私有(private)属性的名称，因此它们占用的字节更少，这也使它们“更私有(private)”，因为标识符可能会随着构建而改变。例如:private mySpecialProperty: string 缩小后将为 p1，编译器将更改类中对此标识符的所有引用以匹配 p1。因此，今天拥有它会起作用，但将来它可能会限制构建功能。

要考虑的另一点是，虽然 Angular 不关心编译器关心的修饰符，因此动态组件创建将受到限制。换句话说，在 html 标记中创建组件将没有任何问题，但使用 ComponentResolver -> ComponentFactor 动态创建组件将受到限制，因为您将无法将这些输入分配给您的实例使用代码的组件。如果您不打算这样做，那很好。

If you're building components to be used by others, public modifier is mandatory for @Input/@Output. The users of you'r component should be able to dynamically create your components.

这也回答了有关在获取对咖啡组件的引用的父/子组件上访问这些属性的问题。只能通过模板标记进行绑定(bind)。例如，您将无法手动注册到在咖啡组件上注册的 EventEmitter。这有时是必需的，请参阅 THIS场景为例。

至于生命周期钩子(Hook)，它不应该有任何影响，因为 Angular 不检查类型，而是检查存在性。

因此，总而言之，在大多数用例中，您不应该有任何问题，但随着您的应用程序的进步，您可能会解决一些问题，也可能不会。将来您可能还必须选择退出高级缩小功能...