RxJS流映射最佳实践：是否需要为UI转换新增独立的Observable流？

结论先行 #

优先选择业务侧就地映射，只有映射逻辑多场景复用时再考虑在核心服务加派生流，绝对不要新增独立的BehaviorSubject存储派生的UI状态。

具体判断标准 #

• 如果UserUI的映射逻辑仅当前单个业务场景使用：直接在用到的业务组件/业务服务内就地映射即可
  示例代码：

  // 业务组件内
  const usersUI$ = this.coreService.users$.pipe(
    map((users: User[]) => users.map(user => ({
      ...user,
      checked: true,
      date: new Date()
    })))
  )
  

  该方案优势：
  • 核心服务不需要维护和特定业务UI绑定的逻辑，避免公共服务不断臃肿，后续业务迭代下线时也不需要修改核心服务代码
  • 不会产生多份状态数据源，从根源避免原始users$更新后派生状态不同步的问题
• 如果UserUI的映射逻辑有3个及以上的业务场景都需要用到：可以在核心服务内新增只读派生Observable，注意不要用BehaviorSubject单独存储状态
  核心服务示例代码：

  // 核心服务仅维护唯一的原始状态数据源（不对外暴露Subject，避免外部随意修改）
  private readonly usersSub = new BehaviorSubject<User[]>([]);
  public readonly users$ = this.usersSub.asObservable();
  
  // 派生的UI状态流，完全从原始流自动生成，不需要手动next更新
  public readonly usersUI$ = this.users$.pipe(
    map(users => users.map(user => ({
      ...user,
      checked: true,
      date: new Date()
    })))
  )
  

通用原则 #

• 单一真实数据源：公共核心服务仅维护一份和UI无关的原始业务状态，所有派生状态都从该唯一数据源自动推导，禁止存储多份可写的状态副本
• 职责单一：公共服务只放跨场景通用的逻辑，和特定业务绑定的UI状态逻辑优先放到对应业务层，避免公共服务被业务代码污染
• 延迟抽象：不要提前为可能的复用做过度设计，只有相同逻辑重复出现2次以上时再考虑抽到公共层

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