JavaScript Asynchronous Calling Framework (Part 1 - Problems & Scenarios)_javascript skills

Problem
In Ajax applications, calling XMLHttpRequest is a very common situation. Especially for client-centered Ajax applications, various operations that need to obtain data from the server are completed through XHR asynchronous calls. However, in single-threaded JavaScript programming, the code style of XHR asynchronous calls is really incompatible with general JavaScript code.

Extra parameters
Consider a divide function. If it were a purely client-side synchronous function, the signature would be like this:

function divide(operand1, operand2 )

However, suppose we are not satisfied with the accuracy of the client-side division, so we transfer the division to the server-side for execution. Then it is an asynchronous function that needs to call XHR, and the signature may be one of the following: :

Copy code The code is as follows:

function divide(operand1, operand2, callback)
function divide(operand1, operand2, successCallback, failureCallback)
function divide(operand1, operand2, options)

We have to introduce new parameters in the signature to pass the callback function, There is no option to make the function a blocking synchronous call.

Transportability
Not only do functions that directly operate XHR need to introduce new parameters, this complexity will also be passed along the call stack. For example, we have encapsulated the four arithmetic operations of addition, subtraction, multiplication and division, and only exposed one operation interface:

function calculate(operand1, operand2, operator)

This calculate function is based on the operator parameter. Call the internal plus, subtract, multiply, divide functions. However, because the divide function becomes an asynchronous function, the entire calculate function has to be transformed into an asynchronous function:

function calculate(operand1, operand2, operator, callback)

At the same time, when calling Any function on the stack that needs to be called to calculate must become asynchronous, unless it does not need to return results from the upper level call function.

Synchronous coexistence
Although the calculate function becomes an asynchronous function, the plus, subtract, and multiply functions it calls are still synchronous functions. Only when divide is called, it is asynchronous. At this time, calculate is an asynchronous synchronization function. Concurrent functions.

What problems will this cause? When the caller of calculate sees the function signature, he will naturally think that calculate is an asynchronous function because it needs to pass a callback function. However, the execution method of calculate is uncertain. Consider the following call:

calculate(operand1, operand2, operator, callback);
next();

This involves two functions, callback and next, which one is executed first and which one is executed last The execution is uncertain, or depends on the specific implementation of calculate.

If the implementation of calculate is, when asynchronous operations are not required, callback is called directly. Then, callback will be called before next when performing addition, subtraction, and multiplication; next will be called before callback when performing division.

If we don’t like this uncertainty, we can change the implementation of calculate and change all synchronous calls to setTimeout form, so that next will definitely be called before callback under any circumstances.

However, the latter approach relies on a higher-cost implementation. Developers may accidentally miss setTimeout (or are just plain lazy), causing the function calling sequence to become uncertain, so we would like to This is a function that the framework helps achieve, and there is no way around it when using the framework.

Scenario
Here, I will give a specific application scenario regarding the above problem. (To simplify the problem, the description has been slightly modified, which is not consistent with the actual application.)

In Baidu Hi web version, we will save a list of user objects on the client, and open the chat window with this user When, we need to read this user's information from it. This operation involves many branches that may be synchronous or asynchronous:

The user object is not cached
Read user information asynchronously
The user object is cached
The user is a friend (information updates will be updated by the server client push)
Read user information synchronously
The user is not a friend (information updates need to be pulled from the client)
Cache information can be accepted
Read user information synchronously
The latest information must be obtained
Read user information asynchronously
You can see that the results of the branch are both synchronous and asynchronous. And these branches are not completed in one function, but in several functions. That is to say, according to the traditional model, some of these functions are synchronous and some are asynchronous. Due to the transitivity of asynchronous, the functions at the top of the final call stack are all asynchronous.

In order to solve this problem, we need to write an asynchronous calling framework, use a unified way to make calls, and combine synchronous and asynchronous calls into one return method.