I have a function foo
which makes an Ajax request. How can I return the response from foo
?
I tried returning the value from the success
callback, as well as assigning the response to a local variable inside the function and returning that one, but none of those ways actually return the response.
function foo() {
var result;
$.ajax({
url: '...',
success: function(response) {
result = response;
// return response; // <- I tried that one as well
}
});
return result;
}
var result = foo(); // It always ends up being `undefined`.
If you're using promises, this answer is for you.
This means AngularJS, jQuery (with deferred), native XHR's replacement (fetch), EmberJS, BackboneJS's save or any node library that returns promises.
Your code should be something along the lines of this:
Felix Kling did a fine job writing an answer for people using jQuery with callbacks for AJAX. I have an answer for native XHR. This answer is for generic usage of promises either on the frontend or backend.
The core issue
The JavaScript concurrency model in the browser and on the server with NodeJS/io.js is asynchronous and reactive.
Whenever you call a method that returns a promise, the
then
handlers are always executed asynchronously - that is, after the code below them that is not in a.then
handler.This means when you're returning
data
thethen
handler you've defined did not execute yet. This in turn means that the value you're returning has not been set to the correct value in time.Here is a simple analogy for the issue:
The value of
data
isundefined
since thedata = 5
part has not executed yet. It will likely execute in a second but by that time it is irrelevant to the returned value.Since the operation did not happen yet (AJAX, server call, IO, timer) you're returning the value before the request got the chance to tell your code what that value is.
One possible solution to this problem is to code re-actively , telling your program what to do when the calculation completed. Promises actively enable this by being temporal (time-sensitive) in nature.
Quick recap on promises
A Promise is a value over time. Promises have state, they start as pending with no value and can settle to:
A promise can only change states once after which it will always stay at the same state forever. You can attach
then
handlers to promises to extract their value and handle errors.then
handlers allow chaining of calls. Promises are created by using APIs that return them. For example, the more modern AJAX replacementfetch
or jQuery's$.get
return promises.When we call
.then
on a promise and return something from it - we get a promise for the processed value. If we return another promise we'll get amazing things, but let's hold our horses.With promises
Let's see how we can solve the above issue with promises. First, let's demonstrate our understanding of promise states from above by using the Promise constructor for creating a delay function:
Now, after we converted setTimeout to use promises, we can use
then
to make it count:Basically, instead of returning a value which we can't do because of the concurrency model - we're returning a wrapper for a value that we can unwrap with
then
. It's like a box you can open withthen
.Applying this
This stands the same for your original API call, you can:
So this works just as well. We've learned we can't return values from already asynchronous calls but we can use promises and chain them to perform processing. We now know how to return the response from an asynchronous call.
ES2015 (ES6)
ES6 introduces generators which are functions that can return in the middle and then resume the point they were at. This is typically useful for sequences, for example:
Is a function that returns an iterator over the sequence
1,2,3,3,3,3,....
which can be iterated. While this is interesting on its own and opens room for a lot of possibility there is one particular interesting case.If the sequence we're producing is a sequence of actions rather than numbers - we can pause the function whenever an action is yielded and wait for it before we resume the function. So instead of a sequence of numbers, we need a sequence of future values - that is: promises.
This somewhat tricky but very powerful trick lets us write asynchronous code in a synchronous manner. There are several "runners" that do this for you, writing one is a short few lines of code but is beyond the scope of this answer. I'll be using Bluebird's
Promise.coroutine
here, but there are other wrappers likeco
orQ.async
.This method returns a promise itself, which we can consume from other coroutines. For example:
ES2016 (ES7)
In ES7, this is further standardized, there are several proposals right now but in all of them you can
await
promise. This is just "sugar" (nicer syntax) for the ES6 proposal above by adding theasync
andawait
keywords. Making the above example:It still returns a promise just the same :)
The following example I have written shows how to
This working example is self-contained. It will define a simple request object that uses the window
XMLHttpRequest
object to make calls. It will define a simple function to wait for a bunch of promises to be completed.Context. The example is querying the Spotify Web API endpoint in order to search for
playlist
objects for a given set of query strings:For each item, a new Promise will fire a block -
ExecutionBlock
, parse the result, schedule a new set of promises based on the result array, that is a list of Spotifyuser
objects and execute the new HTTP call within theExecutionProfileBlock
asynchronously.You can then see a nested Promise structure, that lets you spawn multiple and completely asynchronous nested HTTP calls, and join the results from each subset of calls through
Promise.all
.NOTE Recent Spotify
search
APIs will require an access token to be specified in the request headers:So, you to run the following example you need to put your access token in the request headers:
I have extensively discussed this solution here.
Browser can be divided into three parts:
1)Event Loop
2)Web API
3)Event Queue
Event Loop runs for forever i.e kind of infinite loop.Event Queue is where all your function are pushed on some event(example:click) this is one by one carried out of queue and put into Event loop which execute this function and prepares it self for next one after first one is executed.This means Execution of one function doesn't starts till the function before it in queue is executed in event loop.
Now let us think we pushed two functions in a queue one is for getting a data from server and another utilises that data.We pushed the serverRequest() function in queue first then utiliseData() function. serverRequest function goes in event loop and makes a call to server as we never know how much time it will take to get data from server so this process is expected to take time and so we busy our event loop thus hanging our page, that's where Web API come into role it take this function from event loop and deals with server making event loop free so that we can execute next function from queue.The next function in queue is utiliseData() which goes in loop but because of no data available it goes waste and execution of next function continues till end of the queue.(This is called Async calling i.e we can do something else till we get data)
Let suppose our serverRequest() function had a return statement in a code, when we get back data from server Web API will push it in queue at the end of queue. As it get pushed at end in queue we cannot utilise its data as there is no function left in our queue to utilise this data.Thus it is not possible to return something from Async Call.
Thus Solution to this is callback or promise.
A Image from one of the answers here, Correctly explains callback use... We give our function(function utilising data returned from server) to function calling server.
In my Code it is called as
Javscript.info callback
If you're not using jQuery in your code, this answer is for you
Your code should be something along the lines of this:
Felix Kling did a fine job writing an answer for people using jQuery for AJAX, I've decided to provide an alternative for people who aren't.
(Note, for those using the new
fetch
API, Angular or promises I've added another answer below)What you're facing
This is a short summary of "Explanation of the problem" from the other answer, if you're not sure after reading this, read that.
The A in AJAX stands for asynchronous. That means sending the request (or rather receiving the response) is taken out of the normal execution flow. In your example,
.send
returns immediately and the next statement,return result;
, is executed before the function you passed assuccess
callback was even called.This means when you're returning, the listener you've defined did not execute yet, which means the value you're returning has not been defined.
Here is a simple analogy
(Fiddle)
The value of
a
returned isundefined
since thea=5
part has not executed yet. AJAX acts like this, you're returning the value before the server got the chance to tell your browser what that value is.One possible solution to this problem is to code re-actively , telling your program what to do when the calculation completed.
This is called CPS. Basically, we're passing
getFive
an action to perform when it completes, we're telling our code how to react when an event completes (like our AJAX call, or in this case the timeout).Usage would be:
Which should alert "5" to the screen. (Fiddle).
Possible solutions
There are basically two ways how to solve this:
1. Synchronous AJAX - Don't do it!!
As for synchronous AJAX, don't do it! Felix's answer raises some compelling arguments about why it's a bad idea. To sum it up, it'll freeze the user's browser until the server returns the response and create a very bad user experience. Here is another short summary taken from MDN on why:
If you have to do it, you can pass a flag: Here is how:
2. Restructure code
Let your function accept a callback. In the example code
foo
can be made to accept a callback. We'll be telling our code how to react whenfoo
completes.So:
Becomes:
Here we passed an anonymous function, but we could just as easily pass a reference to an existing function, making it look like:
For more details on how this sort of callback design is done, check Felix's answer.
Now, let's define foo itself to act accordingly
(fiddle)
We have now made our foo function accept an action to run when the AJAX completes successfully, we can extend this further by checking if the response status is not 200 and acting accordingly (create a fail handler and such). Effectively solving our issue.
If you're still having a hard time understanding this read the AJAX getting started guide at MDN.
Another solution is to execute code via sequential executor nsynjs.
If underlying function is promisified
nsynjs will evaluate all promises sequentially, and put promise result into
data
property:If underlying function is not promisified
Step 1. Wrap function with callback into nsynjs-aware wrapper (if it has promisified version, you can skip this step):
Step 2. Put synchronous logic into function:
Step 3. Run function in synchronous manner via nsynjs:
Nsynjs will evaluate all operators and expressions step-by-step, pausing execution in case if result of some slow function is not ready.
More examples here: https://github.com/amaksr/nsynjs/tree/master/examples
Here are some approaches to work with asynchronous requests:
Example: jQuery deferred implementation to work with multiple requests