RxJS scan操作符中mutationFn的工作原理及代码疑问

一、mutationFn的来源 #

上游的fetchCarsGridDataAction$流通过map操作，把fetchCarsForGrid返回的数据转换成了一个函数，这个函数就是scan里接收的mutationFn。

看这段关键代码：

map(data => (vm: CarsGridManagementVM) => ({
  ...vm,
}))

这里map并没有直接返回接口数据，而是返回了一个接收CarsGridManagementVM类型参数、并返回新VM对象的函数。当fetchCarsGridDataAction$发射值时，发射的不是原始数据，而是这个函数，也就是mutationFn。

二、scan与mutationFn的配合逻辑 #

scan的累加器函数逻辑非常直接：

(prevVm: CarsGridManagementVM, mutationFn: (vm: CarsGridManagementVM) => CarsGridManagementVM) =>
  mutationFn(prevVm) as CarsGridManagementVM

• prevVm是scan维护的累加状态，也就是上一次生成的视图模型
• mutationFn是上游流发射过来的状态更新函数，它的作用是接收旧VM，返回新VM
• 每次上游发射mutationFn，scan就调用这个函数，用旧VM生成新VM，作为下一次的累加状态

当前代码里的mutationFn只是浅拷贝旧VM（{...vm}），看起来没实际修改，但这是预留的扩展点——如果要把接口返回的data合并到VM里，只需要修改map里的逻辑：

map(data => (vm: CarsGridManagementVM) => ({
  ...vm,
  cars: data, // 把新数据合并到视图模型中
}))

三、为何无需显式定义mutationFn #

因为mutationFn的逻辑已经在fetchCarsGridDataAction$的map操作里定义完成，上游流会直接把这个函数发射给scan，所以scan只需要接收并执行它就行，不需要再重复定义。

这种模式是RxJS中管理视图状态的常见写法：把状态更新逻辑封装成函数（mutation），通过流发射这些函数，再用scan执行函数更新状态，实现状态的可追溯和集中管理。

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