Angular中组件的字符串@Input属性的属性绑定与属性绑定？答案

【问题标题】：Attribute binding vs property binding for Component's string @Input properties in Angular?Angular中组件的字符串@Input属性的属性绑定与属性绑定？
【发布时间】：2017-11-29 02:26:14
【问题描述】：

要设置组件的字符串@Input()属性，我们可以使用两种语法：

<my-component caption="Hello there" type="primary" someThing="text value"></my-component>

或者：

<my-component [caption]="'Hello there'" [type]="'primary'" [someThing]="'text value'"></my-component>

我完全了解这两种类型的绑定之间的区别。问题是：如果我有一堆我想静态设置的字符串 @Input() 属性，我可以使用简单的属性绑定语法（第一个示例）而不是更多“肉”属性绑定语法（第二个示例）吗？

建议是什么，为什么？ IE。有哪些权衡？最好始终使用属性绑定，即使是设置静态字符串输入？

以下是我能想到的几个缺点：

属性绑定实际上是作为 HTML 属性应用的，例如用户可以通过浏览器的开发工具轻松查看/更改它们。财产绑定不是标记的一部分。
属性绑定可能会发生冲突带有实际的 HTML 属性名称（除非您在它们前面加上 data- 这违背了简单的整个目的）。实际例子已经咬我的是title 属性。
使用 Angular 语言服务进行属性绑定的标记中没有智能感知。

但主要优点是简单。在上面的示例中，您会同意第一种形式更优雅。在我的项目中，似乎大量属性是常量（一次性设置）字符串属性，并且语法在可读性方面产生了实际差异。

那么...对自定义（非 HTML）字符串属性使用属性绑定语法是一种不好的做法吗？（鉴于我知道/可以接受上面列出的一些限制）

【问题讨论】：

标签： html angular binding

【解决方案1】：

我想补充几点：

Attributes 只是简单的static fields。
attributes 变为 properties 时有一条细线。
这里的目标不是简单，modularity 和 reuse-ability 才是。
Property binding 让您对component 有更多控制权，您可以在任何data-driven 或static 场景中使用component。
一个component 与property binding 一起构建可用于20 个不同的项目。
但是如果你没有这样的要求，那么你可以使用attributes。他们很好。
我不会说哪个更好，两者都有自己的用例，但总体而言，property bindings 更强大、更灵活。

最后我想对所有读者提及：
在前端开发中，任何人都可以修改代码。我们用验证只是为了提供流畅的用户体验。除此之外任何人都可以根据需要获取代码或更改 HTML，这就是为什么我们使用服务器端验证。角管线复杂但可以破解。用户可以包装一个 JSON 对象并将其发送到服务器绕过我们所有的验证。所以对于所有新前端的读者开发人员，我们不会太在意安全性，我们会尽力提供良好的用户体验。

【讨论】：