createCallable() 將 React 元件轉換為可以 await。
適用場景：確認對話框、表單模態框、提示訊息、通知、右鍵選單、選擇器——任何概念上會向呼叫者回傳值的 UI。
為什麼選擇 react-call？
簡而言之：顯示和隱藏某個東西時，React state 非常完美。但當互動需要向你回應時，這個模式就開始吃力了——而你為了解決這個問題所構建的，或多或少就是這個函式庫。
宣告式模型中的命令式流程
確認、提示、選擇本來就是命令式的：提出問題、等待、獲得答案、繼續。React state 是宣告式的——它描述的是給定狀態下的 UI 是什麼樣子，而不是一步步回傳值的流程。強迫命令式互動透過宣告式 state 來實現，就是這種不匹配。以下的種種都是其症狀。
react-call 並不會讓 React 變得不那麼宣告式——Root 仍然以宣告式方式渲染其活躍的 calls。它為命令式的那一半提供了命令式 API，await Confirm.call()，並讓渲染留在它該在的地方。每一半都做自己擅長的事。
State 渲染對話框，但它無法回傳答案。
你可以輕鬆地用 React state 來控制對話框——一個顯示它的旗標，甚至是一旦做出的選擇。但 state 無法做到的，是將那個選擇交還給開啟它的命令式程式碼。於是你手動彌補這個差距：回呼 prop，或保存在 state 中的 resolver，提升到共同的父元件——然後決策的結果最終被擱置在那個處理函式中，遠離觸發它的點擊。
「但為何要增加依賴？」
說得對。你可以自己寫一個 promise，這樣就能 await 答案並將流程保持在一處。但那個封裝——一旦它還要處理類型、SSR、每個元件只有一個 Root 的規則、退出動畫，以及同時在畫面上顯示多個 call——那就是 react-call。它約 1 KB，沒有依賴，而且已經寫好並測試過了。
何時使用 React state 才是正確的選擇
這一切並非指「React state 不好」。對於純粹顯示/隱藏切換且不回傳任何東西的情況——例如一個只會開啟和關閉的選單——useState 完全正確，你不該求助於函式庫。界線在於結果：一旦你需要回傳答案、同時在畫面上顯示多個此類元件，或從多處重複使用同一個對話框，那麼 call() 就值得被使用。
組合 — 同時有兩個問題就只是兩個 call 共存，而不是一組你需要手動連接的開啟/關閉旗標。 查看 Stack →
重用 — 定義一次 Callable，即可從任何處理函式、hook 或領域動作中呼叫它。無需為每個畫面重新接線。