problem
In AJAX applications, calling XMLHttpRequest is a common case. In particular, client-centric AJAX applications, various operations that need to obtain data from the server are completed by XHR asynchronous calls. However, in single-threaded JavaScript programming, the code style of XHR asynchronous invocation is really out of tune with the usual JavaScript code.
Extra Parameters
Consider a division function, and if it is a pure client synchronization function, then the signature would be:
function Divide (operand1, Operand2)
However, assuming that we are not satisfied with the accuracy of client division, and then transfer the division to the server side to execute, it is an asynchronous function that needs to invoke XHR, and the signature may be one of the following:
Copy Code code as follows:
function Divide (Operand1, Operand2, callback)
function Divide (operand1, Operand2, Successcallback, Failurecallback)
function Divide (operand1, operand2, Options)
We must introduce a new parameter in the signature to pass the callback function, and we cannot choose to have the function become a blocking synchronous call.
of transitivity
Not only do the functions that directly manipulate XHR need to introduce new parameters, this complexity will also be passed along the call stack. For example, we encapsulate the subtraction arithmetic, exposing only an operational interface:
function Calculate (operand1, Operand2, operator)
The Calculate function calls the internal plus, subtract, multiply, and divide functions according to the operator arguments. However, because the divide function becomes an asynchronous function, the entire calculate function has to be converted to an asynchronous function as well:
function Calculate (operand1, Operand2, operator, callback)
At the same time, any function that requires a call to calculate on the call stack must become asynchronous unless it does not need to call the function up-level to return the result.
Simultaneous coexistence
Although the Calculate function becomes an asynchronous function, it calls the plus, subtract, multiply function, or the synchronization function, which is asynchronous when the call to divide, at which point calculate is an asynchronous synchronous coexistence function.
What kind of problem is this going to bring? The calculate caller sees that the function signature will naturally assume that calculate is an asynchronous function, because it needs to pass the callback function, but the calculate execution is indeterminate. Consider the following call:
Calculate (Operand1, Operand2, operator, callback);
Next ();
This involves callback and next two functions, which are not sure which ones to execute first, or which are dependent on the calculate implementation.
If the implementation of calculate is, call callback directly when no asynchronous operation is required. Then, the callback is invoked before next when the subtraction multiplication is performed, and next is called before callback when the division is performed.
If we do not like this uncertainty, we can change the implementation of calculate, the synchronous call to the SetTimeout form, so that in any case next will be called before callback.
However, the latter approach relies on a higher cost implementation, and developers inadvertently (or lazy) will miss the settimeout, resulting in the sequence of function calls become uncertain, so we would like this is the framework to help implement the function, when the framework can not be used to bypass this.
Scene
Here, I give a specific application scenario for the above questions. (To simplify the problem, the description has been slightly modified and is not consistent with the actual application.) ）
In the Baidu Hi Web page, we will save a list of user objects in the client, and when we open the Chat window with this user, we need to read the user's information from it. This operation involves many branches that may be synchronized and possibly asynchronous:
User Object Not Cached
Read user information asynchronously
User object is Cached
The user is a buddy (information updates are pushed by the server side)
Read user information synchronously
User is not a buddy (information update needs to be pulled by the client)
can accept cached information
Read user information synchronously
Must get the latest information
Read user information asynchronously
As you can see, the results of the branching are both synchronized and asynchronous in the end. And these branches are not done in one function, but are implemented in several functions. That is, in the traditional pattern, these functions are partly synchronous and partly asynchronous, and because of asynchronous transitivity, the final call to the top of the stack function is asynchronous.
To solve this problem, we need to write an asynchronous invocation framework that is invoked in a uniform way, merging both synchronous and asynchronous calls into one form of return.
