Accessing promise state for the sake of tests about when

[augustl]

Slightly off topic, but just came across another use case for accessing promise state. When I get the state data from the server, I need to wrap the .resolve() in a try/catch since the promise might have been resolved before. Alternatively, I can keep track of state separately and only .resolve() once. Would be useful to just do something like if (!deferred.resolved) deferred.resolve().

[briancavalier]

Sorry it took me a bit longer than I expect to respond!

Is mocking the promises, as suggested by @tobie on twitter, an option for testing? I like that idea a lot because then your tests are not dependent on the particular promise implementation, but rather on the Promises/A spec.

Let me know if that doesn't work in your situation and we can figure out something else.

I've been pretty hesitant to provide any way to query a promise's state. One reason is that I think it might encourage people to poll promises, which I feel is an antipattern. I tend to look at them as one-time events rather than something with a queryable state (even though they most certainly are stateful!).

It seems like anytime I've gotten myself into a situation where I felt like I needed a way to query a promise to see if it's resolved or not, I end up figuring out a better way to do what I need to do. Not saying that's the case here, but it's become one of those things that raises a red flag in my mind.

If you do need to branch depending on the state, right now, the only way would be to maintain the state yourself. One simple way would be to use a boolean, but that can be problematic if there's asynchrony and you use a promise callback to set the boolean. Another way that might work in this situation (admittedly without knowing many of the details), is to use a function overwrite to silence subsequent attempts to resolve a deferred. Something like:

var deferred = ...;

function noop() {}

var resolvePromise = function() {
    resolvePromise = noop;
    deferred.resolve();
};

You could also overwrite deferred.resolve/reject directly--although you can't overwrite deferred.resolver.resolve/reject, since the resolver is frozen. For example, wherever you resolve the deferred:

deferred.resolve();
deferred.resolve = deferred.reject = noop;

As long as you don't give out deferred.resolver to anyone, that should be safe. But again, depending on your architecture that may or may not work.

[augustl]

Mocking them will indeed solve all my problems, thanks.

[briancavalier]

Great, glad that worked for you, August.