Promise is designed as a state machine. The state transition from pending to resolve/reject is one-way and unique. There is no so-called cancel state. The addition of cancel will bring more status issues and is not suitable for the Promise model to handle (in this scenario, FRP solutions such as RxJS should be more suitable).
What status problems will cancellation bring? Take e-commerce refunds as an example. You bought something (started a pending promise), but you haven't received it yet (it hasn't been resolved yet). You regretted it and clicked a refund (changed the status to cancel), but the refund process cannot take effect immediately. , needs to be reviewed (you cannot reject it immediately after canceling), then you have paid your salary and don’t want to refund, so you click [Cancel Refund] again. At this time, there is another asynchronous status change (cancel again) , and [Cancel Refund] is also asynchronous. You can also cancel the [Cancel Refund] operation (cancel before canceling?) Don’t forget, at this time, each step of status change can also be mapped to resolve. And reject. Hello students, please draw the state change diagram of the process and code to implement this promise that supports cancel
For example, the page needs to be refreshed once every minute, but the interface is very slow, so when I send a request next time, the last request has not come back. In this case, I want to cancel the last request.
For example, like and cancel like operations If you use promise and you like it by mistake and want to cancel it, you have to wait for the like operation to end before you can operate it So there is an enhanced version of promise → observable
Perform two operations (two Promises) at the same time, cancel the other when one is completed, and finally return the result that succeeds first.
But cancellation is a pitfall. For example, cancellation by multiple threads means an asynchronous exception, which means that the operation is suddenly completely interrupted in the middle of the operation, without giving any chance to recover (otherwise the cancellation will be meaningless), so there is no way to restore or return. roll. Only pure CPU independent computing tasks can be safely canceled.
As for canceling and then canceling "cancel", there is no such thing as the rule is that when you enter the cancel state (half-dead state), you cannot switch to other states.
Promise is designed as a state machine. The state transition from pending to resolve/reject is one-way and unique. There is no so-called cancel state. The addition of cancel will bring more status issues and is not suitable for the Promise model to handle (in this scenario, FRP solutions such as RxJS should be more suitable).
What status problems will cancellation bring? Take e-commerce refunds as an example. You bought something (started a pending promise), but you haven't received it yet (it hasn't been resolved yet). You regretted it and clicked a refund (changed the status to cancel), but the refund process cannot take effect immediately. , needs to be reviewed (you cannot reject it immediately after canceling), then you have paid your salary and don’t want to refund, so you click [Cancel Refund] again. At this time, there is another asynchronous status change (cancel again) , and [Cancel Refund] is also asynchronous. You can also cancel the [Cancel Refund] operation (cancel before canceling?) Don’t forget, at this time, each step of status change can also be mapped to resolve. And reject. Hello students, please draw the state change diagram of the process and code to implement this promise that supports cancel
For example, the page needs to be refreshed once every minute, but the interface is very slow, so when I send a request next time, the last request has not come back. In this case, I want to cancel the last request.
For example, like and cancel like operations
If you use promise and you like it by mistake and want to cancel it, you have to wait for the like operation to end before you can operate it
So there is an enhanced version of promise → observable
Perform two operations (two Promises) at the same time, cancel the other when one is completed, and finally return the result that succeeds first.
But cancellation is a pitfall. For example, cancellation by multiple threads means an asynchronous exception, which means that the operation is suddenly completely interrupted in the middle of the operation, without giving any chance to recover (otherwise the cancellation will be meaningless), so there is no way to restore or return. roll. Only pure CPU independent computing tasks can be safely canceled.
As for canceling and then canceling "cancel", there is no such thing as the rule is that when you enter the cancel state (half-dead state), you cannot switch to other states.