Making an ajax call inside a successful one can be considered bad practice?

Question

Let's take the following piece of code:

$.ajax({
    type: 'POST',
    dataType: dataType,
    url: 'someUrl',
    success: function(result){
        $.ajax({
            type: 'POST',
            dataType: dataType,
            url: 'anotherUrl',
            data: queryToSearch,
            success: function(anotherResult){
                (do something that uses the first one result)
            },
            error: MyObj.defaultAjaxError
        });
    },
    error: MyObj.defaultAjaxError
    });

Can this be considered a bad practice? Does it have any hit on performance? If yes, is there a better way to do something like this?

Answer 1

Use Promises. Hopefully, Promises/A (as implemented in jQuery 1.8+ Deferred Objects), then:

$.ajax({..}) // Promise 1
 .fail(function () {
    // Oops! This will fire if (and only if) Promise 1 failed.
 })
 .then(function () {
    // This will only fire if the first request had no error - was "done"
    // We then return a NEW promise for the 2nd request. In a proper
    // Promises/A, 'then' returns a (new) promise. (jQuery < 1.8 is broken.)
    return $.ajax({..}) // Promise 2
 })
 // Note that these are for the 2nd promise which has been returned from
 // the 'then' above OR from a 2nd promise created automatically by the default
 // failHandler.
 .fail(function () {
    // Oops! This will fire if EITHER the promises (AJAX calls) fails.
    // This happens because we are either binding to our Promise 2
    // or to the auto-rejected promise returned from the default failHandler.
 })
 .done(function () {
    // 2nd promise done - means both are done!
 })

Using when is not appropriate, because that would be "in parallel". (Actually, when could be used with a "stub" promise that is wired to be accepted when the 2nd call completes - however this doesn't benefit from then chaining and it's not possible to meaningfully use the promise from the 2nd call directly for serial execution.)

One interesting thing to note is that fail and done are just shorthands for/restricted forms of then. These methods can (and should) be used for clarity of intent/code.