The expected behavior is that an axios request is sent when it is discovered in the consumers code.

@SashaKoro Really understand your expectation. But I am afraid that axios can't achieve that as it is a promise-based design.

One workaround can be that don't write too much codes after axios calls. If possible, wrap them in another macro task.

axios.get(url)

setTimeout(() => {
   // do other things
}, 0)

@chinesedfan Hey, thanks for the quick response. To clarify further; this is not an issue solely because axios returns a Promise (fetch also returns a promise but does not have this behavior)

Looking at axios internal code, the promise is being created here: https://github.com/axios/axios/blob/master/lib/core/Axios.js#L50 The promise is created in the event that the consumer wants to leverage the interceptor API and perform an async operation inside one of their interceptors, something like (copied from a test):

    axios.interceptors.request.use(function (config) {
      return new Promise(function (resolve) {
        // do something async
        setTimeout(function () {
          config.headers.async = 'promise';
          resolve(config);
        }, 100);
      });

However, not everyone leverages interceptors and creating a promise only when they are used might be a good solution that will fix this issue. (It would also be cool to sniff if the interceptor does an async operation before creating the promise; this would allow consumers to leverage synchronous interceptors without paying a penalty) I'm going to look into this further.

So the issue with wrapping the rest of our code in a timeout block is that it is not just a single function (like in the example), the rest of our code is modules and modules of React and Redux code. It would also have to be handled on a case-by-case basis since we are making dozens upon dozens of different axios calls on our website.

only when they are used might be a good solution that will fix this issue

@SashaKoro Totally agreed with you. The key point is that the real request is send in a then callback, which is so-called micro-task. And it must wait until the current macro task has been finished.

I've got a working proof of concept of a possible solution. My proposed changes revolve around creating a Promise only when necessary. It will cover the following scenarios (behavior will not change):

• If the adapter configuration parameter is specified. This is necessary because the custom adapter function provided by the consumer is not guaranteed to return a Promise. The adapter param looks to be primarily used to simplify testing.

• If the request is canceled via the cancel token. The Promise needs to be created in order for the error to be caught in the .catch block.

• If any request interceptors are declared. This has to be done because there is no guaranteed way to see if the interceptor functions that the user provides are sync or async: discussion
  However, add an optional parameter to the axios.interceptors.request.use function that allows the user to specify if their interceptor is synchronous. Then under the hood iterate over all the request interceptors and if they are all set to be synchronous via the param; execute them synchronously and do not create the Promise pre-emptively.

For all other cases*, a Promise will not be pre-emptively created and the request will be sent in a predictable manner at the time the axios.[method] function is declared in the consumers' code.

*This is safe for response interceptors because the request can be kicked off prior to their attachment.

I'm planning to get the proof of concept into a cleaner state, add comments, post a link to the branch and go over the changes in more detail.

I've cleaned the code up. Here is the branch: https://github.com/SashaKoro/axios/tree/issue2609

The two files that have relevant changes are Axios.js:

SashaKoro@d450b06#diff-91dcec0516f33811ee5fa71297160b3b

And InterceptorManager.js:

SashaKoro@d450b06#diff-02a02ddaa4d79e5a11b08edecfaf1e75

On that branch, I also changed /get/index.html so you can test the behavior if you want. I added minimal comments as I hopefully have made the code mostly self-documenting. If things look good I can move forward with adding unit tests and documentation.

In order to move fast on our end, we ended up forking axios with the changes I've made and deploying to production. The results have been incredible.

This is our homepage before:

And after:

Note the timing of the requests relative to the JS execution. Prior to the change, they were all bunched up at the end of the JS execution, now the requests are being made when they are discovered in the code.

Some of the requests are kicked off up to 500ms faster (this is on Chrome over broadband), on 3G connections we are seeing some requests kicked off up to a second faster.

@SashaKoro Sure. Really appreciated for your continuous updating.

I think it is one of the most annoying things in open source, especially for axios, which is famous and important, but without enough active maintainers. Your pull request is almost there, except for one or two tiny flaws, then I can give it an approval. If no one opposes it, I can even merge it (in fact, it requires more reviewers to check, as it may break the core functionalities). At last, I have no npm publish permission. The real release date still needs lots of our patience.

@chinesedfan Hey, no problem! Totally understandable. I appreciate your feedback, I definitely missed a couple of things in the implementation.