Angular 项目记 与 React 的对比

Question

Angular 好坏都很明显，强处在于

• 强大的工程化
• 默认 TypeScript 配置
• 依赖注入
• 默认 named export
• 等

后几者对于本来就岌岌可危的前端重构和单元测试是一大助力。

弱点在于：

• 模板没有办法支持复杂逻辑，抽取组件较重。这其实 discourage 了组件抽取、模块化这个事情
• 由于上一点，整个前端明显由数据流驱动，又被强行分成 controller 和 view，除了架构本身，缺乏明显的抽象层次

模板这个问题可以认为这是在模板设计思路上 React 的编程式和 Angular/Vue 的 template 式模式的差异；后一个这个事情，就导致你的 controller 各种 parse 数据、存 component 变量、给 view 使用，从「模块化」的角度讲，组件内部是高内聚的， 但东西依然被拆成 component.ts 和 component.html 两个文件，导致业务代码之间关联性差，缺乏抽象。React 由于抽组件更容易，配合 selector 使用部分地解决了这个问题；Vue 通过 filter computed 等内置的语法特性部分地解决了这个问题。总体来说，感觉都比 Angular 要轻量、优雅一些。

这次做的 Angular 项目，面向对象的属性较重（几个险种有不同的加总逻辑有相同的逻辑、依赖于其他的数据），用这种数据驱动的方式就导致所有计算逻辑都放在组件或 service 里，抽象能力不够。也是因此突然发现，当你尝试抽象「数据」和「基于数据的行为」到一起时，它就自然地是「面向对象」了。我们不应该主张「一切皆对象」，而是在应用明显呈现出大量「基于数据其上的行为操作」特征时，想到面向对象提供了一种合理的抽象和模块化的方案，它符合我们对优秀软件的一些想象（SOLID）。

槽点

模板没有 early return，看得人脑疼。

React 里，通过编程方式，可以将异常的、空的逻辑直接返回断掉，从而使 render 逻辑分块，便于阅读：没有评论的话，就返回空，不用再往下读了；有评论的话，就渲染。

render() {
  const { comments } = this.props
  if (comments.length === 2) {
    <EmptyComments />
  }
  
  return comments.map(comment => (
    <Comment content={comment} key={comment.id} />
  ))
}

在模板型 view 里，由于不能编程，只能这样写。你就发现，上下本来是独立的逻辑，现在「联系」到一起了，comment.length 的逻辑其实重复了一遍，你得反应一下才知道「哦，这两个条件是互斥的，显示其中一个就不显示另外一个」。模板规模再大一点（这很有可能，考虑到 Angular 实质上不鼓励模板抽取这种方式），你整个模板都得看完才能理解它的渲染方式。

<empty-comments *ngIf="comments.length <= 2"></empty-comments>
<div *ngIf="comments.length > 2" *ngFor="let comment of comments">
  <comment [content]="comment"></comment>
</div>