我选择 Angular 的完全主观理由

我希望标题足够明显。如果这还不够明显，让我再说得更清楚一些。这完全是我的主观意见。你可能强烈反对我的观点，这没关系。这篇文章并非试图宣称 Angular 比 React、Vue、Svelt 或其他你喜欢的框架更好。它只是在讨论为什么我，John Woodruff，选择在大大小小的个人项目中使用 Angular。老实说，我甚至没有试图说服你使用 Angular。事实上，我真诚地建议，选择一个你最了解的框架，这样你就能尽可能高效地工作。所以，让我们先把这些都说清楚，然后深入探讨我选择 Angular 用于个人项目的带有强烈偏见的理由。请记住，我的言论完全是基于个人观点的，所以请谨慎对待。

固执己见的框架

让我们先来谈谈最热门的话题之一。Angular 是一个固执己见的框架。如果你不确定这意味着什么，简单来说，Angular 框架定义了你该如何构建应用程序，并提供了构建应用程序所需的所有基本工具。它们提供了路由、数据获取、内部数据流等解决方案，所有这些都捆绑在框架本身中。相比之下，React 等框架则没有明确定义你该如何构建应用程序，它只是一个用于构建组件的库。你可以随意选择构建应用程序所需的所有组件库，特别是我上面提到的那些。

那么，为什么这会成为一个热门话题呢？嗯，固执己见或缺乏主见的框架或库都会引发开发者们各种各样的反应。许多开发者非常反对固执己见的框架，而另一些开发者则喜欢固执己见的框架。因此，许多支持或反对 Angular 的论点自然都基于这样一个事实：它是一个高度固执己见的框架。它们对 Angular 应用的构建方式有着严格的规定，并且内置了许多开箱即用的工具。

好了，现在我们来谈谈我的第一个偏见。我喜欢 Angular，因为它是一个有主见的框架。我喜欢它让我不用在上百万个库中挑挑拣拣就能搭建一个复杂的应用。我需要的 95% 都已经包含在 Angular 框架中了。我也不需要决定“如何”构建我的应用，因为 Angular 有一套详细的应用构建风格指南，我可以完全专注于应用的实际实现。

这也是我喜欢在工作环境中使用 Angular 开发大型复杂应用的原因。团队协作时，由于不同团队或团队成员的工作方式不同，经常会产生摩擦。使用 Angular 可以消除很多摩擦，因为有明确的工作方式，因此在整个组织内扩展起来更容易。我曾在工作环境中使用 Angular 和 React 开发过大型复杂应用，发现使用 Angular 应用变得无比轻松，因为没有使用大型 React 应用时遇到的诸多摩擦。这归根结底是因为 Angular 比较固执己见，所以精神负担要小得多。

Angular CLI

啊，Angular CLI。这与之前关于 Angular 固执己见的观点完全一致。Angular CLI 是构建 Angular 应用的最佳方式，因为它严格遵循 Angular 风格指南。它能为你生成一个完整的 Angular 项目，并提供众多生成器命令来添加新的组件、服务、模块等，还为你提供了开箱即用的自动化测试等等。

它还完全控制您的构建过程，这意味着它们全面管理您应用程序的构建和优化。因此，您的所有生产构建都利用了诸如提前编译、源代码压缩、树形优化、样式自动前缀等优化技术。所有这些操作您都需要自己摸索，并使用构建工具以及众多库和插件来完成。与其在这些方面浪费时间，我更乐于知道 Angular CLI 正在为我生成最佳的生产构建，这样我就可以专注于构建出色的功能。

版本更新

Angular CLI 最棒的功能之一（即使不是最棒的功能）就是这个ng update命令。自 Angular 6 发布以来，Angular CLI 就包含了这个命令。它基本上简化了所有版本升级的工作，Angular 团队在使这个命令运行得异常顺畅方面做得非常出色。他们甚至提供了一个超级实用的更新指南，其中提供了详细的说明，但几乎所有指南都说这些更改应该由这个ng update命令自动执行。通常情况下，当你进行重大版本更新时，你必须手动检查应用的更新依赖项，深入研究更新日志，在应用中的多个位置更改代码以删除已弃用或已移除的功能，然后还要进行繁琐的测试以确保没有破坏任何功能。然而，这个命令基本上可以自动完成所有这些操作，包括运行代码迁移，自动将你迁移到最新的推荐语法。只有极少数情况下，更改需要手动干预代码，而且通常情况下，这些问题都能很快得到解决。其余所有操作都由 Angular CLI 完全自动化。

自从这个命令发布以来，每次有新的主要版本发布，我都会花大约 5-10 分钟更新到最新版本。相比之下，主要版本升级有时可能需要几个小时甚至几天才能将大型复杂应用程序更新到最新版本。它甚至允许库作者定义自己的原理图来自动更新他们的库，这对于框架的用户来说非常棒，因为他们可以自动化更新，而不必担心手动更新。每次发布主要版本时，这都为我节省了无数的时间，而当我使用其他不提供这种令人难以置信的功能的框架时，我完全被宠坏了。（这实际上是固执己见的框架的另一个好处，它允许像这样的功能，否则不固执己见的框架是不切实际的）Angular 团队绝对凭借这个功能击败了其他人。

Angular CDK

除了Angular Material之外，还有一个非常棒的小软件包，叫做Angular CDK。CDK是组件开发工具包 (Component Dev Kit) 的缩写，它是一个非常方便的软件包，可以帮助你开发应用程序所需的一些更复杂的组件。它们被称为“行为原语”，你可以用它们来构建你自己的品牌组件。

对于构建组件库的人来说，构建按钮和输入字段等组件相当简单，但还有一些组件则要复杂得多，例如模态框、手风琴、数据表、拖放、树等等。Angular CDK 让您能够轻松构建自己的复杂行为组件，您可以轻松地为这些组件设置样式，以符合公司或项目的品牌形象。不仅如此，这些组件通常比您自己构建的组件更容易访问。正如本文的主题，Angular CDK 通过为您构建这些抽象，帮助您节省大量时间，这样您就可以专注于组件的外观、感觉和实现，而不是更复杂的细节，例如定位、滚动行为等。它为我构建组件节省了大量的时间，并降低了复杂性。如果您使用 Angular 进行构建，即使您不使用 Angular Material，也绝对应该使用 Angular CDK。

依赖注入

出于某种原因，依赖注入是一个热门话题，但依赖注入也是我喜欢使用 Angular 的另一个重要原因。它让我不必费心定义自己的单例模式和工厂模式。相反，Angular 的依赖注入工具让我能够非常轻松地在任何需要的地方提供所需的依赖项，并且操作起来非常便捷。我不需要在一个组件中实例化一个服务，而是可以直接注入我的服务，Angular 的依赖注入将确保我获得正确实例化的服务，如下所示：

// Some service I've defined
@Injectable()
export class MyService { /* ... */ }

// Some component in my app
@Component({ /* ... */ })
export class MyComponent {
  constructor(private service: MyService) {}
}

依赖注入的另一大优势是可测试性更强。我认为自动化测试对于产品及其开发团队的成败至关重要。Angular 中的依赖注入功能让我能够非常轻松地测试、模拟和处理当前测试代码单元外部的依赖项。考虑上面的组件。要模拟一个方法，我只需注入正确的依赖项，然后利用 Jasmine 的间谍功能模拟该方法即可。

describe('MyComponent', () => {
  let service: MyService;

  beforeEach(async () => {
    // Initialize Angular TestBed
    await TestBed.configureTestingModule({
      declarations: [MyComponent]
    }).compileComponents();

    // Inject MyService for mocking
    service = TestBed.inject(MyService);
    // Mock out `sayHello` method
    spyOn(service, 'sayHello').and.returnValue('Hello World!');
  });
});

它使处理大型复杂代码库变得轻而易举，也使测试变得非常简单。依赖注入有缺点吗？当然有。无论你选择哪种模式，总会有一些权衡。最终取决于你愿意做出哪些权衡来换取你认为最有价值的好处。对我来说，Angular 的依赖注入是我选择它而不是其他框架的主要原因之一。

结论

如果你已经忘记了，我再强调一次，这篇文章极度偏颇，完全基于个人观点。我非常喜欢使用 Angular，它是我做业余项目的首选框架，我相信对你们中的许多人来说，它也是一个绝佳的选择。话虽如此，我绝对认为它对很多人来说并非良策。归根结底，你需要权衡每个框架的利弊，决定你愿意做出哪些取舍，并根据你的决定做出选择。对你们中的许多人来说，你的选择可能是 React、Vue、Svelt、Stencil、Ember，甚至可能是 Backbone。这完全没问题。

我写这篇文章的目的是为了阐述我个人选择 Angular 而不是其他框架的原因，并非为了煽动“框架之争”或抨击他人的选择。我始终认为，对于一个项目来说，最好的框架选择是你或你的团队最熟悉的，能够帮助你提高效率，并尽可能减少对目标的权衡。事实上，我喜欢阅读其他人关于他们选择框架（或库、文本编辑器或其他任何东西）的带有偏见的文章，我乐于为他们的成功和快乐感到高兴，而我则享受我自己的选择。如果有人像我一样选择 Angular 来开发他们的业余项目，我很乐意在评论区留言，分享你的理由！如果你想批评 Angular 或其他框架不如 X 或 Y 框架，我恳请你把这些评论留到鼓励他们这样做的帖子里。❤🌈