In Ajax applications, it is common to call XMLHttpRequest. Especially client-centered Ajax applications, all operations that require data retrieval from the server are completed through XHR asynchronous calls.
Problem
In Ajax applications, it is common to call XMLHttpRequest. Especially client-centered Ajax applications, all operations that require data retrieval from the server are completed through XHR asynchronous calls. However, in single-threaded JavaScript programming, the Code style of XHR asynchronous calls is really out of line with General JavaScript code.
Additional Parameters
Consider a division function. If it is a pure client-side synchronization function, the signature will be like this:
Function pide (operand1, operand2)
However, if we are not satisfied with the accuracy of the Division on the client, and transfer the Division to the server for execution, it is an asynchronous function that needs to call XHR, and the signature may be one of the following:
The Code is as follows:
Function pide (operand1, operand2, callback)
Function pide (operand1, operand2, successCallback, failureCallback)
Function pide (operand1, operand2, options)
We must introduce new parameters in the signature to pass the callback function. We cannot choose to change the function to a blocking synchronous call.
Portability
Not only do you need to introduce new parameters for directly operating XHR functions, but this complexity will also be passed out along the call stack. For example, we encapsulate the addition, subtraction, multiplication, division, and Division operations to expose only one operation interface:
Function calculate (operand1, operand2, operator)
This calculate function calls the Internal plus, subtract, multiply, and pide functions based on the operator parameter. However, because the pide function becomes an asynchronous function, the entire calculate function has to be converted to an asynchronous function:
Function calculate (operand1, operand2, operator, callback)
At the same time, all functions that need to call calculate on the call stack must be asynchronous unless it does not need to return results to the function called at the upper level.
Synchronization and coexistence
Although the calculate function becomes an asynchronous function, the plus, subtract, and multiply functions called by it are also synchronous functions. They are only asynchronous when pide is called. At this time, calculate is an asynchronous synchronous function.
What problems will this bring? When the calculate caller sees the function signature, he will naturally think that calculate is an asynchronous function because it needs to pass the callback function. However, the implementation method of calculate is uncertain. Consider the following calls:
Calculate (operand1, operand2, operator, callback );
Next ();
The callback and next functions are involved here. It is not clear which of them is executed first, or it depends on the specific implementation of calculate.
If calculate is implemented, callback is called directly when asynchronous operations are not required. Then, callback will be called before next when performing addition and subtraction multiplication; next will be called before callback when executing division.
If we do not like this uncertainty, we can change the implementation of calculate and change the synchronous call to the setTimeout format. In this way, next will be called before callback in any case.
However, the latter method depends on the high-cost implementation method. If a developer is not careful (or is too lazy), the setTimeout will be missed, resulting in uncertain order of function calls, therefore, we hope this is a function that the framework can help implement and cannot be bypassed when using the framework.
Scenario
Here, I will introduce a specific application scenario for the above questions. (To simplify the problem, the description has been slightly modified, which is inconsistent with the actual application .)
In Baidu Hi web edition, we will save a list of user objects on the client. When opening a chat window with this user, we need to read the user information from it. This operation involves many branches that may be synchronized and asynchronous:
User object not cached
Asynchronously reads user information
User object cached
Users are friends (information updates will be pushed by the server)
Synchronously read user information
The user is not a friend (Information Update needs to be pulled by the client)
Acceptable Cache Information
Synchronously read user information
You must obtain the latest information.
Asynchronously reads user information
We can see that the branch result is both synchronous and asynchronous. These branches are not completed in a function, but in several functions. That is to say, according to the traditional mode, some of these functions are synchronous and some are asynchronous. Due to asynchronous transmission, the top-layer functions on the stack are finally called asynchronously.
To solve this problem, we need to write an asynchronous call framework and call it in a unified way. Both synchronous and asynchronous calls are combined into a return method.
