基于redux-observable实现删除确认弹窗的方案合理性咨询

一、现有方案的合理性 #

整体思路是通顺的：通过uid关联删除请求和弹窗确认动作，还做了依赖注入方便单元测试，拆分展示弹窗、处理确认删除两个流的逻辑也比较清晰。但有个关键隐患：你用let uid在epic内部维护共享状态，当用户快速触发多个删除请求时，后面的请求会覆盖uid值，导致前一个请求的弹窗确认动作无法匹配到正确的uid，最终无法触发删除。这在多并发操作场景下会出bug。

二、是否需要添加takeUntil(action$.ofType(MODAL_NO_CLICKED)) #

需要，但不能直接生硬加在现有代码里。现有方案中，用户点击取消（MODAL_NO_CLICKED）后，当前的uid还保留着，可能会干扰后续的请求。添加takeUntil的核心目的是终止当前未完成的流，清理上下文，但要结合避免共享状态的重构来用——比如在每个独立的请求流里，监听MODAL_NO_CLICKED来终止当前流，同时不需要维护全局的uid。

三、更优的实现方式 #

解决共享uid的问题是核心，我们可以把每个删除请求和对应的弹窗确认流程绑定成独立的流，让每个请求拥有自己的上下文，不会互相干扰。推荐用switchMap（如果希望新请求覆盖旧的）或concatMap（如果希望排队处理）来重构：

const deleteNotificationEpic = (action$, store, dependencies) => {
  return action$.pipe(
    ofType(NOTIFICATION_DELETE_REQUEST),
    switchMap(action => {
      // 每个请求生成独立的uid，避免共享状态
      const uid = dependencies.uid || shortid.generate();
      
      // 先派发弹窗动作，再等待用户的确认/取消操作
      return concat(
        // 第一步：展示确认弹窗
        of(showYesNo({
          message: 'NOTIFICATION_DELETE_CONFIRMATION',
          payload: {
            notificationId: action.notificationId,
            uid,
          },
        })),
        // 第二步：等待用户操作，只响应当前uid对应的弹窗动作
        action$.pipe(
          ofType(MODAL_YES_CLICKED, MODAL_NO_CLICKED),
          filter(({ payload }) => payload.uid === uid),
          take(1), // 只取第一个触发的动作（确认或取消）
          switchMap(modalAction => {
            if (modalAction.type === MODAL_YES_CLICKED) {
              // 用户确认：执行删除请求
              return deleteNotification$(modalAction.payload.notificationId, dependencies).pipe(
                mergeMap(() => of(deleteNotificationSuccess())),
                catchError(error => of(deleteNotificationFailure(error))), // 建议区分成功/失败动作，原代码统一用success不太合理
              );
            } else {
              // 用户取消：可派发取消动作，或直接返回空流
              return of(deleteNotificationCancelled(action.notificationId));
            }
          }),
          // 可选：如果用户再次触发删除请求，终止当前未完成的流
          takeUntil(action$.pipe(ofType(NOTIFICATION_DELETE_REQUEST))),
        ),
      );
    }),
  );
};

这个方案的优势：

• 无共享状态：每个删除请求的uid都是独立的，不会出现多请求互相覆盖的问题；
• 流程连贯：从触发删除请求→展示弹窗→处理用户操作的完整逻辑都封装在一个switchMap里，可读性更强；
• 自动清理：通过take(1)和takeUntil确保流在完成或被中断后自动清理，避免内存泄漏；
• 测试友好：每个请求流都是独立的，测试时可以模拟单个请求的完整生命周期，更容易覆盖各种场景。

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