close

How to extract data out of a Promise

Hello Guys, How are you all? Hope You all Are Fine. Today we are going to learn How to extract data out of a Promise in javascript. So Here I am Explain to you all the possible methods here.

Without wasting your time, Let’s start This Article.

How to extract data out of a Promise ?

  1. How to extract data out of a Promise ?

    to extract data out of a Promise While you can get a value from an awaited Promise inside an async function (simply because it pauses the function to await a result), you can't ever get a value directly out of a Promise and back into the same scope as the Promise itself.

  2. How to extract data out of a Promise ?

    to extract data out of a Promise While you can get a value from an awaited Promise inside an async function (simply because it pauses the function to await a result), you can't ever get a value directly out of a Promise and back into the same scope as the Promise itself.

Method 1

NO you can’t get the data synchronously out of a promise like you suggest in your example. The data must be used within a callback function. Alternatively in functional programming style the promise data could be map()ed over.

If your are OK using async/await (you should it’s awesome) then you can write code that looks synchronous yet retain the asynchronicity of a promise (see @loganfsmyth comments).

const { foo, bar }  = await iAmAPromise.then(result => result.data);

Overall since you are already using ES6 I assume you are also using a transpiler. In which case you should definitely give async/await a try. Just be sure to weight in the decision that as today they are not yet a ratified specification.

Method 2

While you can get a value from an awaited Promise inside an async function (simply because it pauses the function to await a result), you can’t ever get a value directly out of a Promise and back into the same scope as the Promise itself.

That’s because “out of” would mean trying to take something that exists in the future (the eventually resolved value) and putting it into a context (synchronous variable assignment) that already happened in the past.

That is, time-travel. And even if time-travel were possible, it probably wouldn’t be a good coding practice because time travel can be very confusing.:)

In general, if you find yourself feeling like you need to do this, it’s good sign that you need to refactor something. Note that what you’re doing with “result => result.data” here:

Promise.then(result => result.data, errorHandler);
// rest of script

..is already a case of you working with (literally, mapping over) the value by passing it to a function. But, assuming that “// rest of script” does something important related to this value, you probably want to continue mapping over the now updated value with yet another function that then does something side-effect-y with the value (like display the data on the screen).

Promise
    .then(result => result.data)
    .then(data => doSomethingWithData)// rest of script
    .catch(errorHandler);

“doSomethingWithData” will be called (if it’s ever called) at some unknown point in the future. Which is why it’s a good practice to clearly encapsulate all that behavior into a specific function and then hook that function up to the Promise chain.

It’s honestly better this way, because it requires you to clearly declare a particular sequence of events that will happen, explicitly separated out from the first run through all of your application code’s execution.

To put it another way, imagine this scenario, hypothetically executed in the global, top-level scope:

const { foo, bar } = Promise.then(result => result.data, errorHandler);
console.log(foo);
//...more program

What would you expect to happen there? There are two possibilities, and both of them are bad.

  1. Your entire program would have to halt and wait for the Promise to execute before it could know what “foo” & “bar” would… nay, might be. (this is what “await,” inside an async function, does in fact do: it pauses the entire function execution until the value is available or an the error is thrown)
  2. foo and bar would just be undefined (this is what actually happens), since, as executed synchronously, they’d just be non-existent properties of the top-level Promise object (which is not itself a “value,” but rather a quasi-Monadic wrapper around getting an eventual value OR an error) which most likely doesn’t even contain a value yet.

Summery

It’s all About this article. Hope all method helped you a lot. Comment below Your thoughts and your queries. Also, Comment below which method worked for you? Thank You.

Leave a Comment