Modal.confirm在设置closable为true的情况下，onCancel传入的close函数参数为undefined

[Hubartist]

Reproduction link

Steps to reproduce

modal.confirm config参数配置closable为true，设置onCancel为车close => close() ，点击右上方的关闭icon

What is expected?

点击关闭按钮后正常关闭

What is actually happening?

点击后报错close不是个function

Environment	Info
antd	4.21.7
React	18.3.0
System	Monterey 12.4
Browser	google

[afc163]

没开 closable 时按 ESC 关闭时也会触发。

[Wxh16144]

没开 closable 时按 ESC 关闭时也会触发。

我去看看这个问题吧，我来补充 PR

[Wxh16144]

文档 Modal.method() 的 API 里面写了 onCancel 的定义是 function(close)

按照问题复现 config 传入参数。

现目前情况
a. 按下 ESC 会自己关闭了，不需要 通过 close 方法关闭
b. 点击关闭图标，会 自己关闭，不需要 通过 close 方法关闭
c. 点击取消按钮，不会 自己关闭，需要 通过 close 方法关闭

？？？
是解决 a 和 b 的 onCancel 的 close 参数不是一个 function 问题吗？但是问题是 ESC 和 图标 操作后弹窗已经关闭了，再调用 close 方法好像没啥意义。

如果实现用 Modal.method() 打开的弹窗，都需要通过 close 方法去关闭，会影响以前用护逻辑。

所以这块的逻辑，我好像有点理不清楚，这种逻辑的测试用例貌似也没有。

[Wxh16144]

我大概捋清楚逻辑了

当我们使用 Modal.method() 或 Modal.useModal() 打开弹窗时。

关闭弹窗有 3 种方式

1. 点击蒙层关闭 [maskClosable=true]
2. ESC 关闭 [keyboard=true]
3. 点击右上角图标关闭 [closable=true]

如果是 confirm 类型，footer 会多出一个取消按钮 (确定按钮等左边)，此时关闭弹窗在前面 3 种方式中又多出一种，点击 取消 按钮关闭。

但是官方源码对于 前面 3 种关闭形式定义为 triggerCancel, 这时候不能通过 onCancel:function(close) 的第一个参数 close 去调用。

对于 confirm 类型弹窗，点击 取消 按钮这个行为才需要通过 close 方法手动关闭。

我 GET 到的官方设计目的是，前 3 种方式关闭，属于 antd 功能。不需要开发者手动 close, onCancel 则表示 点击遮罩层或右上角叉或ESC关闭的回调。
而 confirm 类型弹窗的 取消 按钮行为是开发需要关心的逻辑。所以交给开发者去手动 close。 前 3 种的 onCancel 还是正常执行。

对此我解决方法是多加一个判断(需要先修复 undefined问题)，或者具体等官方具体解答一下设计场景。

const config = {
  title: 'issues/36581',
  closable: true,
  content: <code>Test</code>,
  onCancel(close) {
    if(close && close.triggerCancel) {
      // 前面 3 种关闭类型；点击遮罩层、右上角叉、ESC关闭 的回调
      return;
    }
    // do something
    close()
  },
};

Modal.method(config)

// 或者 Modal.useModal() 用法 

// ...
const [modal, contextHolder] = Modal.useModal();
modal.method(config)
//..

另外一个粗暴的解决方案

const config = {
  title: 'issues/36581',
  closable: true,
  content: <code>Test</code>,
  onCancel(close) {
    lodash.isFunction(close) && close()
  },
};

Modal.method(config)

最后不得不提一下，官方对这块儿的文档描述还是不够细致，期待补充。（逃～～

[yoyo837]

你已经捋的这么清楚了，来帮忙补一下文档？

[Wxh16144]

当然没问题。不过我觉得这块内容是不是需要你们再讨论一下， 比如 这里 的类型推导。貌似没有必要使用拓展 arguments。

1. confirm 类型弹窗的 取消 按钮，是否也可以直接 antd 做关闭操作，而不用开发去关闭。想不到业务场景。
2. 对于 第 1 点，修正类型推导后。是否需要补充更多的 Unit Test。
3. 要把之前的都否决么，所有的关闭操作，都交还给开发者。（完全按照文档提供的 close 行为，但我觉得这个方案对以前用户影响挺大的

[afc163]

1. close 作为 onOK/onCancel 第一个参数是早起版本给到用户异步决定关闭时机的方式，具体解法是 onCancel 如果有第一个参数时，则默认不关闭，需要用户手动调用。如果没有参数，则直接关闭。
2. 这个方式不是最合理的方案，所以后面加了返回 Promise 的方案。
3. confirm 里默认没开 closable 和 maskClosable，点击 x 和 mask 和 ESC 退出应该都没有考虑在异步关闭的场景内。（因为没法 loading ，确实也不合适做异步关闭。

我建议不大改这个逻辑了，在这几个场景给 onOK/onCancel 注入一个空 function 避免报错就好了。

[Wxh16144]

在这几个场景给 onOK/onCancel 注入一个空 function 避免报错就好了。

好的，我去 看一下这个逻辑，尝试去实现看看。单测就不需要补充了吧。

[afc163]

单测需要的