How are you calling your original ajax requests?
– NakedBrunchSep 14 '10 at 14:07

2

What do you mean by "done" ? I understand it as "all requests have finished either successfully or not" (resolved or rejected). But you may mean "all requests have finished successfully" (resolved). see all the variations in api.jquery.com/category/deferred-object
– Adrien BeSep 11 '14 at 8:50

If you need deeper control over the failure modes of the ajax scripts etc., you can save the object returned by .when() - it's a jQuery Promise object encompassing all of the original ajax queries. You can call .then() or .fail() on it to add detailed success/failure handlers.

This should be marked as a correct answer because it's simple, efficient and works great. Also, it should be noted that $.when returns a Promise object which has more useful methods, not only .done. For example, with .then(onSuccess, onFailure) method you could react when both requests succeed or at least one of them fails.
– skaleeJun 8 '12 at 8:24

1

Is it possible to bunch the requests ajax1..4 into an array and pass that?
– andigMay 5 '13 at 9:43

29

Be careful with the fail case. Unlike done, fail fires immediately on the first fail and disregards the remaining deferreds.
– Ryan MohrJul 2 '13 at 0:08

1

@skalee thanks for highlighting the fact that an onFailure function could be attached. As I pointed out in a comment to the OP's question: he might want to indicate more precisely what he meant by "done". "Ryan Mohr" did also have a very good point regarding the fact that fail behaves differently as done, some further reading to be done about Promises I guess html5rocks.com/en/tutorials/es6/promises
– Adrien BeSep 11 '14 at 8:57

1

It is great to give people exposure to the when method, and to promises in general, but I think this isn't the best answer. If any of those ajax functions anywhere down the line create another ajax request, and then don't integrate that new promise into the chain correctly... those requests will escape this technique. For example, I can't use this technique without modifying the Shopify library I'm using for ajax add-to-cart behaviour, because it wasn't written in a 'promisy' way, and never returns the xhr objects it creates. Does this make sense? Still a great answer, though!
– ZiggyDec 22 '14 at 22:46

If you want to wait until all ajax requests are finished in your document, no matter how many of them exist, just use $.ajaxStop event this way:

$(document).ajaxStop(function () {
// 0 === $.active
});

In this case, there is no need to guess how many requests can be in an application that might finish in the future. In some cases ajax requests can be part of a function's inner logic, which can be quite complicated (e.g. calling other functions), and in that case, you might not wait until said function is done with its entire logic rather than only waiting for the ajax part to complete.

$.ajaxStop here can also be bound to any HTML node that you think might be modified by ajax.

Again the purpose of this handler is to know when there is no activeajax not to clear or reset something.

P.S. If you don't mind using ES6 syntax, then you can use Promise.all for known ajax methods. Example:

+1 Much better than other answers in case you have to deal with 3rd party scripts with anonymous callbacks/closures.
– kaiserSep 30 '13 at 13:50

5

@kaiser Valid point but it's not what the question was asking. It's not very good if you don't want to wait for all AJAX calls to return. The question is specific about waiting for the AJAX calls you've made on your own (called inside another function, as the OP wrote). Some other code may have made another AJAX call that you don't want to wait for.
– Juan MendesOct 23 '13 at 23:24

6

Compared to the when() solution, it has the advantage to work even if the number of ajax calls is not known.
– Alexis DufrenoyJun 19 '14 at 13:06

5

Compared to the when() solution, it has the large disadvantage not to work well together with other components, since it shares a document-wide global state. If there is some long polling going on continuously, it might even never fire.
– BergiJul 27 '14 at 12:20

NOTE: The above answers use functionality that didn't exist at the time that this answer was written. I recommend using jQuery.when() instead of these approaches, but I'm leaving the answer for historical purposes.

-

You could probably get by with a simple counting semaphore, although how you implement it would be dependent on your code. A simple example would be something like...

This seems like it would overly complicate a trivial problem.
– ChrisSep 14 '10 at 14:29

2

It's really not all that complicated. Counting semaphores are a common mechanism in CS. If you prefer though, the example using jQuery queues would work as well without having to implement the semaphore yourself.
– BBonifieldSep 14 '10 at 15:00

1

I do not see a problem with the semaphore counter, however, I do see a problem with the idea of having FOUR functions to handle the resulting callback. You should define a function first, then reference that function in each .get(). That way at least you do not duplicate that code. Not only that but declaring a function(){} each time allocates memory each time! Rather bad practice if you could call a statically defined function.
– Alexis WilkeJan 12 '15 at 4:30

1

@AlexisWilke This is a 4.5 year old answer, and it was meant to be an example of how semaphores and queues work. You're thinking a little too hard about this, and I don't think CAPITALIZATION TO MAKE A POINT is necessary.
– BBonifieldJan 22 '15 at 18:00

1

Well... I'm not the one who gave you a -1... and I understand that answers do tend to age. Yet, people keep finding them and as far as I know it is not forbidden to give info to people who will potentially make use of them still today.
– Alexis WilkeJan 23 '15 at 9:32

I think, this is by far, the best solution... cheers
– ValJul 2 '13 at 10:40

4

This assumes that you know there won't be any other AJAX requests on the page, not a very good assumption
– Juan MendesOct 23 '13 at 23:27

As of jQuery 1.8, the .ajaxStop() method should only be attached to document.
– GeomorilloApr 20 '14 at 4:33

1

Correct me if I'm wrong but won't this turn your project into an "old school web forms" site? I mean if you your entire page has to wait for a request before it can continue then what's the point of the ajax request in the first place?
– BillRuhlJan 22 '15 at 21:39

Even though this question has over million answers, I still didn't find anything useful for my case. Let's say you have to deal with an existing codebase, already making some ajax calls and don't want to introduce the complexity of promises and/or redo the whole thing.

We can easily take advantage of jQuery .data, .on and .trigger functions which have been a part of jQuery since forever.

This runs contrary to standard jQuery/Javascript practice. AJAX is always supposed to be asynchronous. You should use jQuery.when() instead.
– SystemParadoxApr 24 '12 at 14:50

42

It's terribly bad idea! Never ever do that! Blocking = not responding to user actions at all, even to scrolling or anything! (Also, async: false is going to be deprecated in jQuery 1.8.)
– skaleeJun 8 '12 at 7:48

24

This is a horribly bad idea. DO NOT USE THIS ANSWER.
– TaurenDec 27 '12 at 23:27

18

HOW DOES THIS HAVE 21 UPVOTE... Sorry, 20 UPVOTES???
– trgragliaJul 10 '13 at 14:48

Your setTimeout() does NOT take a sleep. In this case, you just block all tabs until done becomes true.
– Alexis WilkeJan 12 '15 at 4:24

1

I think that is this topic asking for: "Wait until all jQuery Ajax requests are done".
– ChinaHelloWorldJun 8 '15 at 0:52

1

Have you tested this code? my expectation is that done will never be true while the while loop is still running. If the while loop is running, the event loop can't continue and therefore will never run the callback to the ajax success.
– Kevin BJun 8 '15 at 21:22