使用Redux Observable取消旧请求，仅触发地图移动后的最新API请求

这个场景我太熟悉了——地图拖拽时频繁触发位置更新，要是每个小移动都发请求，不仅浪费服务器资源，还可能出现旧请求晚于新请求返回、导致地图数据错乱的问题。你已经用了debounceTime来过滤高频触发的action，但要彻底取消正在处理中的旧请求，switchMap就是你需要的核心操作符！

原理说明 #

• debounceTime(500)：先过滤掉500ms内连续触发的FETCH_NEARBY_STORES action，只有当用户停止拖拽超过500ms时，才会传递最新的action到下一个操作符。
• switchMap：当新的action进来时，它会自动取消上一个还处于pending状态的Observable（也就是你的API请求），只订阅并处理最新的那个请求。哪怕旧请求已经发出去但还没收到响应，switchMap会直接终止它，不会让它触发后续的success/failure action。

完整代码示例 #

import { Observable } from 'rxjs';
import { switchMap, debounceTime, map, catchError } from 'rxjs/operators';

const fetchNearbyStoresEpic = action$ => 
  action$.ofType(FETCH_NEARBY_STORES)
    .debounceTime(500) // 延迟500ms，避免小幅移动触发请求
    .switchMap(action => 
      // 替换为你的实际数据请求逻辑
      db.collection('stores')
        .near({ center: action.payload.coords, radius: 1000 })
        .get()
        .pipe(
          map(snapshot => ({
            type: FETCH_NEARBY_STORES_SUCCESS,
            payload: snapshot.docs.map(doc => doc.data())
          })),
          catchError(error => Observable.of({
            type: FETCH_NEARBY_STORES_FAILURE,
            payload: error.message,
            error: true
          }))
        )
    );

关键注意点 #

• 别把switchMap换成mergeMap：mergeMap会同时处理所有请求，不会取消旧的；concatMap会按顺序排队执行，也不符合“只保留最后一个”的需求。
• 如果你的API请求是基于fetch或者axios，要确保请求能被取消：RxJS的switchMap会通过终止Observable来触发取消逻辑，所以你的请求需要支持取消（比如用axios的CancelToken，或者把fetch包装成可取消的Observable）。不过Firestore的get()请求，RxJS的包装已经处理了取消逻辑，直接用就行。

这样组合下来，既能减少不必要的请求，又能确保只有最新的请求结果会更新你的应用状态，完美解决地图移动时的请求混乱问题！

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