Angular状态管理中订阅异步数组，如何避免过度重渲染？

问题1：避免列表全量重绘，仅更新变更属性的实现方案 #

• 给*ngFor添加trackBy函数：这是最直接的优化方案，通过指定列表项的唯一标识（如产品ID），让Angular能识别出已存在的列表项，仅重绘状态发生变更的项，而非全量删除重建。
  组件内定义函数：

  trackProductById(index: number, product: Product): number {
    return product.id;
  }
  

  模板中使用：

  <tr *ngFor="let product of products$ | async; trackBy: trackProductById">
    <!-- 行内元素 -->
  </tr>
  

• 拆分独立子组件+OnPush变更检测：把每行封装成独立子组件，子组件通过Store的选择器单独订阅自身对应的产品数据，同时设置ChangeDetectionStrategy.OnPush。父组件仅维护产品ID列表，单个产品变更时，只有对应子组件会更新，父组件和其他子组件不受影响。
  子组件配置：

  @Component({
    selector: 'app-product-row',
    templateUrl: './product-row.component.html',
    changeDetection: ChangeDetectionStrategy.OnPush
  })
  export class ProductRowComponent {
    @Input() product$: Observable<Product>;
  }
  

  父组件模板：

  <tr *ngFor="let productId of productIds$ | async">
    <app-product-row [product$]="store.select(getProductById(productId))"></app-product-row>
  </tr>
  

• 精细化Store选择器：针对单个属性创建选择器，在模板中单独订阅该属性的Observable。比如仅订阅产品的修改日期，只有当日期真正变化时，才更新对应的DOM节点。
  示例模板代码：

  <td>{{ store.select(getProductLastChangedDate(product.id)) | async }}</td>
  

问题2：Angular中状态管理库的必要性与distinctUntilChanged的可行性 #

• Angular自带的变更检测确实能处理很多局部状态更新场景，比如单个组件内的列表修改、输入框双向绑定同步，这种场景下不用状态管理库也能正常工作。但状态管理库的价值体现在全局状态共享、异步逻辑统一管控、状态变更可追溯等场景，比如跨多个组件共享产品列表、统一处理来自不同地方的产品修改请求时，Store的优势就很明显。
• 针对列表项使用distinctUntilChanged()完全可行：
  • Elf的select方法默认会结合distinctUntilChanged做引用比较，如果你需要针对复杂对象或属性做深度比较，可以在创建选择器时自定义比较逻辑：

    const getProductName = (productId: string) => createSelector(
      getProductsState,
      state => state.find(p => p.id === productId)?.name,
      { distinctUntilChanged: (prev, curr) => prev === curr }
    );
    

  • 配合OnPush组件使用时，只有当属性真正发生变化时才会触发组件更新，能有效避免不必要的重绘。
• 如果你的场景只是单一组件内的简单列表管理，用BehaviorSubject维护Observable即可；但涉及到复杂状态流转或跨组件共享时，状态管理库依然是更可靠的选择。

内容的提问来源于stack exchange，提问作者Pasha Bolokhov