約束がキャンセルできないのはなぜデメリットなのでしょうか

Question

どのような場合に約束をキャンセルする必要がありますか?

Answer 1

Promise はステート マシンとして設計されており、保留状態から解決/拒否への状態遷移は一方向であり、いわゆるキャンセル状態はありません。 cancel を追加すると、さらに多くのステータスの問題が発生するため、Promise モデルで処理するには適していません (このシナリオでは、RxJS などの FRP ソリューションの方が適しています)。

キャンセルするとどのようなステータスの問題が発生しますか?電子商取引の返金を例に挙げてみましょう。何かを購入しました（保留中の約束を開始しました）が、まだ受け取っていません（まだ解決されていません）。後悔して払い戻しをクリックしましたが（ステータスがキャンセルに変更されました）、払い戻しプロセスは有効になりません。すぐに確認する必要があります (キャンセル後すぐに拒否することはできません)。その後、給与を支払ったので返金したくないので、もう一度 [返金をキャンセル] をクリックします。この時点で、別の非同期ステータス変更が発生します。 (再度キャンセル) 、[返金のキャンセル] も非同期です。また、[返金のキャンセル] 操作をキャンセルすることもできます (キャンセルする前にキャンセル?)。このとき、ステータス変更の各ステップもマッピングできることを忘れないでください。そして拒否する。学生の皆さん、キャンセルをサポートするこの Promise を実装するプロセスとコードの状態変化図を描いてください。

Answer 2

たとえば、ページは 1 分ごとに更新する必要がありますが、インターフェースが非常に遅いため、次回リクエストを送信したときに最後のリクエストが戻ってこない場合、最後のリクエストをキャンセルしたいとします。

Answer 3

たとえば、「いいね！」と「いいね！」のキャンセル
Promiseを使用していて、誤って「いいね！」を押してキャンセルしたい場合は、「いいね！」操作が終了するまで待ってから操作する必要があります
そのため、Promiseの拡張バージョンがあります→観察可能

Answer 4

2 つの操作 (2 つの Promise) を同時に実行し、一方が完了したらもう一方をキャンセルし、最後に最初に成功した結果を返します。

しかし、キャンセルには落とし穴があります。たとえば、複数のスレッドによるキャンセルは非同期例外を意味します。これは、操作が途中で突然完全に中断され、回復する機会が与えられないことを意味します (そうしないと、キャンセルは無意味になります)。したがって、ロールを回復または戻す方法はありません。安全にキャンセルできるのは、純粋に CPU に依存しないコンピューティング タスクのみです。

キャンセル後の「キャンセル」については、キャンセル状態（半死状態）に入ると他の状態に移行できないルールなので、そんなことはありません。