Angular2 @Inputs应该是公共的，还是可以/应该通过将它们设为私有来拥有更严格的API? [英] Should Angular2 @Inputs be public or can/should we have a stricter API by making them private?

问题描述

我正在将Angular2与Typescript一起使用

假设我的应用程序组件模板中包含以下内容:

Suppose I have the following in my app component's template:

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

我的coffee-cup组件:

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

  @Input() 
  public coffee = 0;

}

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

I am currently unsure of what my Input should look like. It could look like this:

@Input()
public coffee = 0;

或

@Input()
private coffee = 0;

我目前倾向于将成员变量咖啡设为私有.

I am currently leaning towards making the member variable coffee private.

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

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

The way that I am viewing a component is that there are two separate APIs to interact with it:

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

1. The template API, which consists of the @Inputs and @Outputs
2. The Typescript API which consists of all of the public properties and methods

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

I haven't checked what occurs in the following situation, however, it may change the answer:

• 假设咖啡会员是公开的.如果我的appComponent使用@ViewChild访问CoffeeCup并设置了咖啡成员，生命周期挂钩(例如ngOnChange)会触发吗?

• Suppose the coffee member is public. If my appComponent gets access to CoffeeCup using @ViewChild and sets the coffee member, will the lifecycle hooks (like ngOnChange) fire?

要重申这个问题: Angular2 @Input应该是公开的还是可以/应该通过将其设为私有来拥有更严格的API?

To restate the question: Should Angular2 @Inputs be public or can/should we have a stricter API by making them private?

推荐答案

首先，从API设计的角度来看，@Input表示公开.从角度角度来看也是如此，这些装饰器描述了与组件交互的界面.

First, from an API design perspective @Input implies public. This is also true from angular perspective, these decorators describes the interface to interact with a component.

@Input装饰器或任何其他meta装饰器由angular使用，目的是让角度了解您的意图，并更好地了解模板及其与组件类的关系.

The @Input decorator, or any other meta decorator is used by angular in a way of letting angular know about your intent and have better understanding of the template and it's relations with the component class.

在某些情况下，变更检测引擎也会使用它.例如，@Input是更改检测所跟踪的字段，它向CD引擎暗示应监视此属性.

It's also used, in some cases, by the change detection engine. For example, @Input is a field tracked by the change detection, it hints to the CD engine that this property should be monitored.

具有@Input装饰器的私有属性在运行时不会有任何影响.此修饰符是虚拟的，在TypeScript转换为JavaScript之后就消失了.

Having a private property with an @Input decorator shouldn't have any effect in runtime. This modifier is virtual and it's gone after TypeScript to JavaScript compilation.

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

However, there are some effects that might occur depending on your environment:

一般来说，拥有TypeScript和元数据的一个巨大好处就是拥有一个智能的IDE，这意味着IDE可以在您编码时为您提供帮助.拥有私有属性可能会或不会影响这，具体取决于每个IDE的实现. 在属性上具有@Input会导致IDE在您为该组件编写HTML标记时在智能感知窗口中向您显示该属性.

A great benefit of having TypeScript and metadata in general is having a smart IDE which means that the IDE can help you while you code. Having a private property might or might not effect that depending on the implementation of each IDE. Having @Input on a property will result in the IDE showing you that property on an intellisense window when you write the HTML markup for that component.

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

Another risk factor is future support for minification/uglification in typescript. Private properties, as the name suggests, are used inside the class nowhere else. This trait means the complier can change the names of private properties so they take less bytes, it also makes them "more private" as the identifier might change from build to build. For example: private mySpecialProperty: string after minification will be p1 and the compiler will change all references to this identifier in the class to match p1. So, having this today will work but in the future it might limit build features.

要考虑的另一点是，尽管angular不关心编译器所做的修饰符，所以动态组件的创建将受到限制. 换句话说，使用html标记创建组件将可以正常工作，但是使用ComponentResolver -> ComponentFactor动态创建组件将受到限制，因为您将无法使用代码将这些输入分配给组件实例. 如果您不打算这样做，那就很好.

Another point to consider is that while angular does not care about modifiers your compiler does, so dynamic component creation will be limited. In other word, creating components in html markup will work without any issues but dynamically creating components using the ComponentResolver -> ComponentFactor will be limited since you won't be able to assign those inputs to the instance of your components using code. If you're not planning to do so, you're good.

如果您要构建供他人使用的组件，则@Input/@Output必须使用 public 修饰符.您组件的用户应该能够动态创建您的组件.

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.

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

This also answers the question about accessing these properties on a parent/child component getting reference to the coffee component. Binding will be possible via template markup only. For example, you won't be able to manually register to EventEmitters registered on the coffee component. This is sometimes required, see THIS scenario as one example.

对于生命周期挂钩，它应该没有任何作用，因为angular不会检查类型，而是进行存在性检查.

As for lifecycle hooks, it should not have any effect since angular does not check the type but does an existance check.

总而言之，在大多数情况下，您应该不会遇到任何问题，但是随着应用程序的进步，您可能会解决一些问题，或者没有解决.将来您可能还必须退出高级缩小功能...

So, to sum up, in most use cases you shouldn't have any issues but as you'r app progresses you might tackle some issues, or not. You might also have to opt-out of advanced minification features in the future...

这篇关于Angular2 @Inputs应该是公共的，还是可以/应该通过将它们设为私有来拥有更严格的API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！