带加载器逻辑的嵌套订阅反模式代码优化咨询

原有代码核心问题 #

• 存在嵌套订阅的RxJS反模式，新增数据源时需要持续嵌套回调，维护成本极高
• 两个图片接口请求串行执行，必须等待Unsplash接口返回后才会发起Pexels接口请求，无端拉长加载耗时
• 加载状态逻辑混乱，中间重复设置unsplashPhotosLoaded = false，最终依赖硬编码的setTimeout修改状态，时机不可靠，容易出现接口还没返回就提前标记加载完成的问题
• 业务初始化逻辑直接写在构造函数中，不符合Angular开发规范，构造函数仅应用来做依赖注入

优化后代码 #

import { forkJoin, catchError, of, delay } from 'rxjs';
import { OnInit } from '@angular/core';

export class YourComponent implements OnInit {
  constructor(
    private courseContentFacade: CourseContentFacade,
    private changeDetectorRef: ChangeDetectorRef
  ) {}

  ngOnInit(): void {
    // 并行执行所有数据源请求
    forkJoin([
      // 处理Unsplash数据源
      this.courseContentFacade.getUnsplashPhotos().pipe(
        takeUntil(this.ngUnsubscribe),
        catchError(err => {
          console.error('Unsplash接口请求失败', err);
          return of(null); // 单个接口失败不阻塞整个流
        })
      ),
      // 处理Pexels数据源
      this.courseContentFacade.getPexelsPhotos().pipe(
        takeUntil(this.ngUnsubscribe),
        catchError(err => {
          console.error('Pexels接口请求失败', err);
          return of(null);
        })
      )
    ])
    // 若业务确实需要延迟展示，保留此处delay逻辑即可，替代原有的setTimeout
    .pipe(delay(environment.production ? 2500 : 1000))
    .subscribe(([unsplashPhotos, pexelsPhotos]) => {
      // 逐个处理各数据源返回结果
      if (unsplashPhotos) {
        this.parseUnsplashPhotos(unsplashPhotos);
      }
      if (pexelsPhotos) {
        this.parsePexelsPhotos(pexelsPhotos);
      }
      // 所有数据源处理完成后统一更新状态
      this.unsplashPhotosLoaded = true;
      this.pexelsPhotosLoaded = true;
      this.courseMediaItemsLoaded = true;
      // 手动触发变更检测
      this.changeDetectorRef.markForCheck();
    })
  }
}

优化说明 #

• 使用RxJS的forkJoin操作符实现多请求并行执行，所有请求全部完成后才会触发回调，天然满足全部拉取完成再修改状态的需求。后续新增数据源只需要往forkJoin的数组中新增对应请求逻辑即可，无需调整代码结构
• 彻底消除嵌套订阅，代码层级扁平，可读性和可维护性大幅提升
• 移除了不可靠的硬编码延迟逻辑，状态更新时机和实际请求完成时机完全绑定，不会出现状态和实际加载情况不一致的问题
• 每个数据源的请求、异常处理逻辑独立，可单独调整不影响其他数据源
• 初始化逻辑迁移到ngOnInit生命周期钩子，符合Angular开发规范
• 新增了单接口异常兜底，单个数据源请求失败不会导致整个流程中断，其他正常返回的数据源仍可正常处理

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