使用Angular组件的四个技巧-InfoQ

要点：

给组件起个好名字

正确地使用事件

遵循 Rule of One

保持模块化，最小化双向绑定

知道该在什么时候使用组件

如果想要提高应用的质量，那就需要提高代码的质量。这可能意味着需要理解一个新思想，也可能意味着以一种更好、更有效的方式实现现有的思想。例如，学会以最有效的方式使用 Angular 组件，可以帮助你创建更易升级、运行更平稳、更具前瞻性的应用。

从.5 版本的 AngularJS 开始，组件就成为 Angular 的一部分，它为代码的组织和回收提供了一种便捷的方式。Angular（Angular2 的简称）与其说是 Angular 1.x 的升级，不如说是“续集”，它在移动支持和其他功能的基础上进行了完全地重写。这里，1.x 中使用的控制器完全被组件取代。无论是否曾经使用或想继续坚持 1.x，无论是从零学起还是在跨越阶段，为了确保代码尽可能地优雅且不会过时，你都需要开始使用组件。无论属于以上哪一类，都可以在这里找到很多帮助简化流程的方法。

什么是组件？

Angular 组件是一种简化指令，它的配置更简单，类似于使用 Web 组件。虽然新结构和特性一直鼓励良好的编码实践，但它们并不能保证一定能够达到预期的效果。最后，这些问题都归因于人类的大脑：可能是程序员的问题，也可能是咖啡质量的问题。

就像使用任何类型的模块或类一样，需要由你来确保创建的代码是否符合逻辑、可读、可重用，并且不会占用不必要的资源。在这篇文章中，将介绍四个强大的技巧来帮助你更好地利用 Angular 组件。

1. 好的命名

玫瑰无论叫什么名字都是香的…

你可以成为世界上最好的程序员，但如果你的命名规范没有任何韵律或缘由，那你就够不上了。当然，不管是说避免使用随意的“神奇数字”（使用常量！），还是抵制缩写变量的诱惑（“HRT”又是做什么的？），对于任何一种代码来说都是这样的。Angular 组件的命名也不例外。完美情况下，组件的命名应具备高“可读性”，把它们放到你的代码中看起来就像英语一样流畅。更重要的是，在几个月后你重读代码时，还能弄懂它实际是做什么的。而且即便你想不起来，但还可以弄懂它们之前调用了什么，这样不是很好吗？

一个常见的命名约定就是在特征后面加上类型（例如：feature.type.js）。在注册组件名称时，使用驼峰式拼写法，例如 FeatureType。这样做很简单，而且逻辑上说得过去。你也可以选择其他方法，但是注意一定要保持一致，疯狂背后也要保持某些条理。

当然，在编写组件内的脚本时，你也应当坚持同样的逻辑。所有的变量都应该易于理解且明显区别于指令，并在必要时做好注释。即便你是在创建一个个人项目，并且从未打算公诸于世，你也应该使用逻辑化的输入和输出，为你的组件定义一个良好的公共接口。

同样的，为组件定义良好的生命周期，并实现生命周期钩子（lifecycle hook）以提供合理的结构。

所有这些都需要花费更多一点的时间，而当你在构建必要但无趣的组件时可能会急于求成。也许你是一个拥有“全局观”的程序员，不想在小问题上费力。就算如此，花点时间用完整命名（和注释）编写好组件将会在后期为你节省大量的时间。如果你是团队中的一员，无论团队大小，这都尤为关键。

2. 以正确的方式使用事件

除了保持良好的命名规范和定义良好的 API 之外，确保你的组件所触发的事件也应该具有良好的命名，这样它们可以更好地与其他组件发生交互。想清楚你想要暴露出哪些东西，相比于使用双向数据绑定（稍后会讨论更多），这可能是个更好的选择。使用 $emit 或者 $broadcast，要知道，有时候你需要与你不了解的组件发生交互，而且你也没有必要了解它们。使用 $rootScope 在整个组件树中触发事件。请记住，如果另一个组件使用了相同的事件名称，可能会导致意外的 bug。

这都是关于前瞻性规划和正确命名的。如果你正是那种喜欢做电子表格和一丝不苟的工作清单的人，那你会如鱼得水很容易就接受这些想法。

说到事件，请务必熟悉那些在组件生命周期中触发的与生命周期有关的事件。它包括组件第一次初始化的 $onInit()，还有 $onChanges() 和 $onDestroy()。记住这些事件，并用它们组织你的组件流。

3. 不要太过复杂，记住 Rule of One

能力越大，责任越大。虽然编写具有多个 Angular 组件的大型脚本非常诱人，但其实遵循“Rule of One”要好得多。也就是说，每个文件只包含一个组件，并且尽量保持每个文件少于 400 行代码。这明显让代码更加易于阅读、浏览和维护。在使用 Git 这样的源码控制系统时，它还可以避免冲突，防止出现变量重复之类的问题。

除此之外，要努力保持模块化。这样就可以确保在将来的项目中能够快速获取和重用组件。本着同样的精神，可以去尝试创建代表特征区域的模块，构建一个整合一切的应用程序根模块，并创建必要的流程。

同样，这也就是为什么要使用良好命名的具有公共API 的组件。将你的应用程序看做一个组件树。每一个组件都通过最小化的双向数据绑定来清晰定义输入和输出。

这也会让你的代码更加直观和容易理解。与其面对一大坨面条式代码，不如构建自己的功能，通过检查每个组件的工作方式进行调整或简化。要注意：这种良好的代码结构可能会对你产生功能膨胀的诱惑。当你很轻易就能给Web 应用添加新功能时，为什么不做呢？请记住，简易性在程序的每个层面都是很有益的。通常更好的是集中精力去做一件事，并在简单、可重用的代码的前提下把这一件事做到极致。

4. 知道该在什么时候使用组件

最后，确保你知道该在什么时候使用组件。组件比使用指令更简单，因此它也鼓励简单、轻量的代码。对于使用 AngularJS 的人，改用 Angular 变得更加容易，并且能基于组件架构对代码进行优化。如果还没有在你的工作流程中使用 Angular 组件，是时候开始了。

同样，要认识到组件的局限性。它们不适合需要在编译和预链接函数中（这些都不可用）执行操作的指令。还有，它们不能访问高级指令定义选项（优先权、终端等），并且当你想要用一个 CSS 类或属性代替一个元素触发它时，你应该坚持使用指令方法。

组件也需要管理和重用。你可以像 Material2 或其他的框架那样把组件组合为集合库，或者将它们作为单独的包发布（可能不会那么简单）。你也可以使用一个开源组件库来创建自己的可重用组件库，而不需要包的配置开销。这样可以把组件组合在一起，同时又能够单独地查找、修改和使用它们。正确的工作方法可以帮助你实现跨应用程序的Angular 组件的模块化、管理和重用。

除了习惯和拒绝改变之外，下面是一些开发者仍然依赖.directive() 的另一个原因。一些编程人员为了保持简洁，会简单地选择可以在整个代码中使用的方法。但其实使用组件可以节省大量的样板文件，更少的非组件指令实际上让他们变得更优秀。所以，简而言之，确保你使用了组件，更重要的是要用得很好。