Multiple requests because the network cannot guarantee the response order, how to ensure that the order of the list results generated after obtaining all the response results is the same as the request order?

see that many people misunderstand that it has been sent 10 times at a time, which is added like this:

if the user can click the button continuously and send a request one time at a time, a li, will be generated after each response result. Because of the influence of the network status, the request sent out may respond first. If you click 10 times, how to ensure that the order of the 10 li is the same as the order of the request?

the answer to using Promise.all is definitely wrong, because you can"t predict when the user clicks the button. The user may complete 10 clicks in a second or two, but it may also be done in 10 seconds. It certainly can"t be said that I wait for users to click 10 times before using Promise.all requests, not to mention that the actual situation is not necessarily 10 times.
this is the only question that I didn"t answer very well in an interview, so I was quite impressed. At first, the Promise.all, I also answered was directly negated. Later, I mentioned that I carried the relevant parameters in the request message, returned in the response, and implemented it locally as a mapping relationship, but the interviewer was still not very satisfied. Later, after I asked, the interviewer only mentioned the idea and said a few words. I don"t remember very clearly. After looking up the data, it seems that the request response contains a Request-Id field and uses UUID as the value. I"m not sure if I haven"t practiced it!

Mar.01,2021

Promise.all can guarantee the order, but will not trigger until all requests are completed

function p1(time) {
    return new Promise(function (resolve, reject) {
        setTimeout(function () {
            resolve(time);
        }, time);
    })
}

Promise.all([p1(5000), p1(1000)]).then(function (res) {
    console.log(res);//[5000,1000]
});

I don't know if you're talking about X-Request-ID . If so, I don't know how to use this header to distinguish different requests, unless it's server-side cooperation.

what I've come up with is to use a self-increasing closure variable to distinguish each AJAX request, which a lot of people upstairs have thought of.

the next step is how to insert

  • elements in the appropriate place based on the value of the closure variable after the request returns, to ensure that the order after insertion is the same as the order in which the request was clicked (rather than the order in which the request was returned).

    my solution is to append a

  • element on request and set it to be hidden, while setting a data, value to the value of the closure variable.

    when the request returns, find the corresponding

  • element according to the closure variable, insert the content and display it. It looks like this:

      

    if similar problems are encountered in the actual project, but not in the interview, and must be returned smoothly , because sometimes the second request needs the result of the first time. I will use the button to become disabled after the user clicks the button and before the request does not come back. Only when the request is returned successfully can the next request be made. The reason is that you can never predict whether a user will be a cat or a dog. so the best way is not to give users a chance to click continuously

  • Menu