This question already has an answer here:
Is there a way to tell if an ES6 promise is fulfilled/rejected/resolved? [duplicate]
(1 answer)
Closed 6 years ago.
Suppose some code does
// promise.js
let p = new Promise(() => { /* ... */ })
export default p
where Promise is an ES6 Promise. Suppose some other code has a reference only to p. How can that code tell if p is resolved or not?
// other.js
import p from './promise.js'
// console.log('p is resolved?', ______)
Is there something we can fill in the blank with that would show true or false depending on whether the promise is resolved or not?
Quoting the MDN documentation:
By design, the instant state and value of a promise cannot be inspected synchronously from code, without calling the then() method.
So, you need to call the .then method.
The ES6 Promise constructor does not have a property that can tell you the state of the promise. You need to do something like this:
import p from './promise.js'
var isResolved = false;
p.then(function() {
isResolved = true;
});
// ... At some point in the future.
console.log('p is resolved?', isResolved);
There is an internal property called PromiseState but you can't access it. Here is the spec.
Related
This question already has answers here:
Resolve Javascript Promise outside the Promise constructor scope
(26 answers)
When would someone need to create a deferred?
(2 answers)
Closed 5 years ago.
I created this little helper to expose resolve and reject outside of the Promise's constructor
export function createPromise() {
let resolve,reject;
let promise = new Promise((r,j) => {
resolve = r;
reject = j;
});
Object.assign(promise,{resolve,reject});
return promise;
}
Because sometimes it's just really awkward to wrap your entire script in
new Promise((resolve,reject) => {
// hundreds of lines of code, most which have nothing
// to do with this Promise but I need the Promise object
// at the top level somewhere so that I can expose it,
// but it won't be resolved until some deeply nested construct is hit
})
Or to give a more concrete example:
let p1 = kb.createPromise();
let p2 = kb.createPromise();
Promise.all([p1,p2]).then(() => {
$('#calendar-bookings').scrollIntoView({
duration: 200,
direction: 'y'
});
});
$('#bookings-table')
.dataTable(getOptions(dtSourceUrl, {date, driverOptions}))
.one('draw.dt', () => p1.resolve());
ReactDOM.render(<VehicleTimeline start={dateMom.toDate()} onLoad={() => p2.resolve()}/>, document.getElementById('vehicle-timeline'));
This way I also don't have to worry about whether resolve() is called synchronously before I even get a chance to bind my .then. [I stand corrected, the .then will fire immediately] I think this is pretty clear: create two promises, bind the .then, and only after is it even conceivable that they're resolved.
Sure, this would allow anyone who you've passed your Promise off to to resolve it (i.e. giving control away from the Promise creator and to the consumer) but if the consumer fires it early, that's their loss because presumably they're the ones interested in the event, no?
Also, this would give the consumer the ability to reject() the Promise which they could abuse as a sort of Promise cancellation. I'm not saying that's a good idea, but I don't think the extra freedom is necessarily bad either.
Is there anything else I'm missing? Any problems with my createPromise method?
This is a variation of the deferred pattern except that you return the promise object with the resolve/reject functions in the promise object. The original deferred pattern created an object with the promise and the resolve/reject functions separately. So you can pass out the promise without exposing the controls.
To be honest, there are very little places where actually breaking out of the constructor scope is needed. In my opinion it's a little bit easier to make a mistake with this pattern and end up with unresolved promises than with the constructor pattern. As far as I can tell really, the only benefit from the constructor pattern over the deferred pattern that you get is that you can throw and reject the promise immediately (through a sync mistake).
This question already has answers here:
Is it bad practice to have a constructor function return a Promise?
(5 answers)
Closed 6 years ago.
I am new to javascript, I need some help understanding how promises(using bluebird) should be used. Below is my code and I want the constructor to initialize a property after property is resolved.
var getCookie = function(object, someParams) {
return connect(someParams)
.then(function(response){
self.cookie = response.cookie;//this should be done as part of object initialization.
done();
});
}
var app = function(){
var self = this;
getCookie(self);
//how to make sure that return happens after promise is resolved?
return self;
}
how to make sure that return happens after promise is resolved?
You can't. The app function will return before the promise is resolved. That is even guaranteed by JavaScript.
How to call promise object in constructor to set a property
You don't.
Instead you have something like a factory method that creates a new instance of the class, and returns a promise that resolves to the instance.
Example:
function getCookie(someParams) {
return connect(someParams)
.then(function(response){
return response.cookie;
});
}
function App() {}
function getApp() {
var app = new App();
return getCookie(params)
.then(function (cookie) {
app.cookie = cookie;
return app;
});
}
// Usage
getApp().then(function(app) {
// use app
});
One uses promises for asynchronous processes. Constructor functions are synchronous. While you can use promises in constructors, the returned instance won't be fully initialized until the promise is resolved. But your code would never know when that is.
That's why having a factory method that returns a promise that resolves to the class instance if the more reliable way.
This question already has answers here:
How do I return the response from an asynchronous call?
(41 answers)
Closed 3 years ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
I need to get the response.data out of the promise so it can be returned by the enclosing function. I know, I probably can't do it the way I've coded it because of normal JavaScript scope. Is there any way, it can be done?
The console.log at #1 produces the correct data. console.log #2 always produces 'a';
function addSiteParentId(nodeId) {
var theParentId = 'a';
var parentId = relationsManagerResource.GetParentId(nodeId)
.then(function(response){
theParentId = response.data;
console.log(theParentId); // #1
});
console.log(theParentId); // #2
return theParentId;
}
Any pointers would be appreciated.
One of the fundamental principles behind a promise is that it's handled asynchronously. This means that you cannot create a promise and then immediately use its result synchronously in your code (e.g. it's not possible to return the result of a promise from within the function that initiated the promise).
What you likely want to do instead is to return the entire promise itself. Then whatever function needs its result can call .then() on the promise, and the result will be there when the promise has been resolved.
Here is a resource from HTML5Rocks that goes over the lifecycle of a promise, and how its output is resolved asynchronously:
https://web.dev/promises/
I also don't like using a function to handle a property which has been resolved again and again in every controller and service. Seem I'm not alone :D
Don't tried to get result with a promise as a variable, of course no way. But I found and use a solution below to access to the result as a property.
Firstly, write result to a property of your service:
app.factory('your_factory',function(){
var theParentIdResult = null;
var factoryReturn = {
theParentId: theParentIdResult,
addSiteParentId : addSiteParentId
};
return factoryReturn;
function addSiteParentId(nodeId) {
var theParentId = 'a';
var parentId = relationsManagerResource.GetParentId(nodeId)
.then(function(response){
factoryReturn.theParentIdResult = response.data;
console.log(theParentId); // #1
});
}
})
Now, we just need to ensure that method addSiteParentId always be resolved before we accessed to property theParentId. We can achieve this by using some ways.
Use resolve in router method:
resolve: {
parentId: function (your_factory) {
your_factory.addSiteParentId();
}
}
then in controller and other services used in your router, just call your_factory.theParentId to get your property.
Referce here for more information:
http://odetocode.com/blogs/scott/archive/2014/05/20/using-resolve-in-angularjs-routes.aspx
Use run method of app to resolve your service.
app.run(function (your_factory) { your_factory.addSiteParentId(); })
Inject it in the first controller or services of the controller. In the controller we can call all required init services. Then all remain controllers as children of main controller can be accessed to this property normally as you want.
Chose your ways depend on your context depend on scope of your variable and reading frequency of your variable.
You have to return a promise instead of a variable.
So in your function just return:
return relationsManagerResource.GetParentId(nodeId)
And later resolve the returned promise.
Or you can make another deferred and resolve theParentId with it.
This question already has answers here:
setting a variable to get return from call back function using promise
(2 answers)
Closed 8 years ago.
I'm new to Promise's and I'm trying to wrap my head around getting the value.
Here's an idea of what I'm trying to do:
API = {
get: function() {
return new Promise(function(res) {
setTimeout(function() {
res('foo')
}, 1000)
})
}
}
var foo = API.get()
console.log(foo)
It's important that var foo = API.get() remains as it is.
Any idea what to do here?
Promises are still asynchronous. You still can't inspect their value in synchronous code.
You need:
API.get().then(function(result) {
// Resolved value from the Promise object returned by API.get()
console.log(result);
});
API.get() returns a promise object, you then invoke the .then() method on that object.
Another more verbose way would be:
var fooPromise = API.get();
fooPromise.then(function(result) {
console.log(result);
});
Promises are about something happening in the future; you cannot examine their eventual values now unless you are in possession of a time machine.
I am not suggesting you do this, but merely for didactic purposes, if you really want your code to function as you seem to, you could redefine console.log to be promise-aware:
console.log = function() {
var old_console_dot_log = console.log.bind(console);
return function(maybe_promise) {
Promise.resolve(maybe_promise).then(old_console_dot_log);
};
}();
(This version only handles one argument; handling more is left as an exercise.)
Now when you say console.log(foo), it will log the resolved value of foo, but only when it is good and ready, one second from now.
This question already has an answer here:
How to return fully resolved promise?
(1 answer)
Closed 7 years ago.
I use a method that expects a promise. Sometimes however, the promise is resolved instantly. Currently, if the promise is resolved right away, I still pass the promise, and use the following:
function instantAction()
{
var defer = $q.defer();
// Actions that are performed instantly
defer.resolve();
return defer.promise;
}
If there a way, to just return the resolve directly, such as something along the lines of return $q.resolve() and skip those two extra lines?
As #Blackhole and #ExpertSystem said above,
$q.when(<Data or 3rd-party Promise>) will return a promise.
It's intended to make an Angular promise out of data or a 3rd party promise.
See the docs here