@befe/brick-comp-popover v0.2.87

2021 BREAKING CHANGES

• props.mouseEnterDelayInMS -> props.mouseEnterDelay
• props.mouseLeaveDelayInMS -> props.mouseLeaveDelay
• props.focusDelayInMS -> props.focusDelay
• props.blurDelayInMS -> props.blurDelay
• props.actionsAlign 默认值跟随 theme.defaultDialogActionsAlign 为 'right'

FAQ

为什么非控制型 PopoverConfirm 在 onConfirm 时马上关闭，而不支持 "根据（同步或异步的）运行结果" 进行关闭？

首先，从设计层面看，“浮层 Popover” 是一个相对轻便的 “确认浮层”，其存在是为了在一些情景下替代“模态弹窗”，以提供一种相对“非强烈打断”的体验

• PopoverConfirm 只是具体到 “二次确认”这个交互，对应阻断性的 “模态二次确认弹窗”
• 作为轻量交互，那么其提示内容应该是简单易读的（简短文字），同时意味着其业务逻辑应是极其简单的，相应的组件在功能设计上，只提供了最简单的“确认/取消”功能

所谓“确认”前的校验，乃至异步操作等情景需要，可以从以下方面考虑：

• 校验情况1，放到“确认浮层” 里的内容是“复杂”的，需要用户进一步输入东西，由于不是简单“二次确认” ，本身也不是 PopoverConfirm 的适用情况，而是 Popover 甚至是 Dialog (应该考虑浮层 vs 弹窗，哪种能更合理地业务交互需求)
• 校验情况2，只是提交前的工序，不需要上述的用户进一步输入，那么这个校验工序，应该在打开浮层之前，即用 beforeChange 根据校验情况确定是否打开浮层
• 异步操作（如确认后的提交），并不需要、也不应该等待并根据异步结果来决定是否关闭，而是在浮层关闭之后进行，即认为提交是“二次确认”的后续工序

将上述 “校验情况2” 和 “异步操作” 作为 “PopoverConfirm 的前道/后道工序”，而不是作为 “PopoverConfirm 要完成的业务” 是基于：

• 无论校验还是异步操作，都是需要将运行结果反馈给用户，PopoverConfirm 作为一个轻量的内容器，承载能力有限，将结果体现在上层容器（比如页面toast）更为合理
• 有助于简化交互流程，试考虑如果“将校验、提交作为 PopoverConfirm 要完成的业务”，那么：
  • 提交，提交完成前的 loading ，cancel 都要在浮层的业务中处理才算完整
  • 校验，校验失败后用户一般是需要做些修改或者放弃，但总要自行关闭浮层

当然，肯费力气，上述反馈、loading、cancel 总可以都塞进去体现并妥善处理，但已经被认为不是一个轻量的“确认浮层”了。业务足够复杂，那么应该考虑弹窗作为载体更合适。

非控制型 Popover 不支持 "根据（同步或异步的）运行结果"，在上述的内在原因之外，还有个直接的问题：

• 作为轻便的"确认浮层"，click 触发的 Popover 有个特性是点击浮层外即关闭（focus、hover 触发的浮层不应作为"确认浮层"，不在讨论之列）
• 这一特性除了体现"随时、快速"，也是为了避免用户同时点开多个浮层这么一个一个被认为不聚焦而无意义的用户行为
• 这一特性和"根据（同步或异步）的运行结果关闭" 是矛盾的，具体一点就是，当点击确认还在等异步结果回来时，就点击浮层外使其关闭

为了避免这些的问题，所以非控制型 Popover 是不支持 "根据（同步或异步的）运行结果" 的。

而对于控制型用法（控制 props.visible），Popover 已经将显示行为的控制权交出，解决上述矛盾、合理处理交互行为的责任也相应交出。 但上述关于 "Popover 作为一个轻量的确认浮层" 的种种交互推论依然成立，应该遵守，可对比参考上文 demo cases 的 AsyncButton vs AsyncButtonValidation vs AsyncButtonNotRecommended