函数响应式编程中保持图表服务无副作用的常用实现模式咨询

核心设计原则 #

FRP场景下这类无状态服务的核心设计逻辑是纯流编排 + 所有IO/副作用外置：服务内部仅保留与业务逻辑相关的纯转换、流合并、去重、防抖等无副作用逻辑，不执行任何有副作用的操作（包括HTTP请求、DOM修改、定时器创建等）。

你当前的思路是「端口隔离」模式的雏形，只是实现方式可以更贴合FRP的流组合特性，不需要手动维护双向的流注入与抛出。

常用标准实现模式 #

模式1：依赖注入副作用执行函数（优先推荐） #

适合绝大多数常规场景，代码最简洁，耦合度最低。核心逻辑是将HTTP请求这类副作用执行函数作为入参注入服务，服务内部仅做流的编排，不关心请求的具体实现。

服务实现示例

// 服务内部完全无副作用，仅做纯逻辑编排
function createChart(timeRange$, refresh$, fetchFn) {
  // 合并所有触发数据请求的信号源
  const requestTrigger$ = combineLatest([timeRange$, refresh$]).pipe(
    map(([timeRange]) => ({ 
      startTime: timeRange.start, 
      endTime: timeRange.end 
    })),
    // 去重、防抖等纯逻辑全部放在服务内部实现
    distinctUntilChanged(isEqual)
  );

  // 调用注入的请求函数获取数据，内部不感知请求的具体实现
  const data$ = requestTrigger$.pipe(
    switchMap(req => fetchFn(req))
  );

  // 生成ViewModel的纯转换逻辑
  return data$.pipe(
    map(rawData => transformToViewModel(rawData))
  );
}

调用示例

const viewModel$ = lineChart.createChart(
  timeRange$,
  refresh$,
  // 副作用（HTTP请求）完全在调用侧定义，服务无感知
  (req) => someService.fetchData(req)
);
viewModel$.subscribe(viewModel => renderMyChart(viewModel));

该方案的优势是服务完全纯净化，单元测试时直接传入mock的请求函数即可，不需要依赖任何HTTP客户端，调用侧代码也最简洁。

模式2：端口适配器模式（高灵活性场景适用） #

适合需要对请求流做全局统一处理的场景（比如全局加loading、统一错误拦截、请求缓存等），核心是把请求触发流作为输出端口暴露，把响应流作为输入端口接入，完全隔离内部逻辑与外部副作用。

服务实现示例

function createChart(timeRange$, refresh$) {
  const requestTrigger$ = combineLatest([timeRange$, refresh$]).pipe(
    map(([timeRange]) => ({ 
      startTime: timeRange.start, 
      endTime: timeRange.end 
    })),
    distinctUntilChanged(isEqual),
    share() // 多订阅场景下不会重复触发请求信号
  );

  // 暴露纯转换函数，将外部传入的响应流转为ViewModel
  const createViewModel$ = (data$) => data$.pipe(map(transformToViewModel));

  return [requestTrigger$, createViewModel$];
}

调用示例

const [requestData$, createViewModel$] = lineChart.createChart(timeRange$, refresh$);
// 直接用操作符串联请求与响应流，不需要嵌套订阅、不需要手动维护Subject
const data$ = requestData$.pipe(
  switchMap(req => someService.fetchData(req))
  // 可在此处统一加loading、错误处理等全局逻辑
);
const viewModel$ = createViewModel$(data$);
viewModel$.subscribe(viewModel => renderMyChart(viewModel));

相比你原本的实现，该方案去掉了手动调用data$.next的步骤，完全用流的组合实现数据流转，更符合FRP的设计范式。

选型建议 #

• 无特殊需求的常规场景优先选择依赖注入副作用执行函数，代码量最小，维护成本最低
• 需要对请求/响应流做统一的全局处理、或者需要对接多个不同的数据源时，选择端口适配器模式，灵活性更高

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