createCallable() 将一个 React 组件转换为你可以 await 的东西。
适用场景：确认框、对话框、表单模态框、提示通知、通知、上下文菜单、选择器——任何在概念上向调用者返回值的 UI。
为什么选择 react-call？
简短版：对于显示和隐藏某物，React 状态是完美的。当交互需要给你一个答案时，这个模式就开始吃力了——而你为了补偿所构建的东西，或多或少就是这个库。
声明式模型中的命令式流程
确认框、提示框、选择器本质上是命令式的：提出一个问题，等待，得到一个答案，继续。React 状态是声明式的——它描述的是在给定状态下 UI 是什么，而不是一个返回值的逐步流程。通过声明式状态强制实现命令式交互，这就是不匹配之处。以下所有内容都是其表现。
react-call 并没有让 React 变得更非声明式——Root 仍然声明式地渲染其活跃的调用。它给了命令式部分一个命令式 API，即 await Confirm.call()，并将渲染留在它该在的地方。每一部分都做自己擅长的事。
状态渲染对话框。但它无法返回答案。
你可以很容易地在 React 状态中保持一个对话框——一个显示它的标志，甚至一旦做出选择。状态不能做的是将这个选择交回给打开它的命令式代码。所以你需要手动搭建桥梁：一个回调 prop，或者一个保存在状态中的 resolver，提升到共同的父组件——而决策的结果最终被困在那个处理器中，远离触发它的点击。
“但为什么要添加一个依赖？”
有道理。你可以手动编写一个 promise，这样你就可以 await 答案并将流程保持在一个地方。但那个封装——一旦它还要处理类型、SSR、每个组件一个 Root 的规则、退出动画以及同时屏幕上多个调用——就是 react-call。它大约 1KB，没有依赖，并且已经写好并经过测试。
什么时候 React 状态是正确选择
这些都不是在说“React 状态不好”。对于一个纯粹的显示/隐藏开关，不返回任何东西——一个只是打开和关闭的菜单——useState 完全正确，你不应该去找一个库。分界线在于结果：当你需要返回一个答案，同时屏幕上出现几个，或者同一个对话框从多个地方重用时，call() 就值得了。
组合——同时提出两个问题只是两个调用共存，而不是一组你手动连接的打开/关闭标志。查看 Stack →
复用——定义一次 Callable，从任何处理器、hook 或领域操作中调用它。无需在每个屏幕上重新连接。