Is it necessary to wrap a promise in a function?

Question

I have this situation :

import processAsyncCall from "../helpers/processAsyncCall";

const promiseWrapper = () => new Promise((res, rej) => { /* [1] */ });
const onResolve = () => { /* [2] */ };

dispatch(processAsyncCall(promiseWrapper, onResolve));

1. The promiseWrapper contains a promise that will resolve when a certain action is made (ex: fetch a file, update content, etc.).
2. This method will be called when the promise inside the promiseWrapper has resolved.

---

Let's take a look at processAsyncCall.

export default (
  promiseWrapper,
  onResolve = null,
) => (dispatch, getState) => {
  dispatch(showLoading());
  promiseWrapper()
    .then(result => {
      if (onResolve !== null && typeof onResolve === "function") {
        onResolve(dispatch, getState)(result);
      }
    })
    .catch(() => console.log("ERROR_IN_ASYNC"))
    .finally(() => dispatch(hideLoading()));
  });
};

The important part is promiseWrapper().then(result => { /* ... */}).

I execute the function promiseWrapper to create the Promise on the spot.

---

My question :

Is it necessary to wrap a promise in a function to ensure that it is not resolved before it is processed?

I had this problem where the then callback wouldn't work if I passed my Promise directly as a parameter.

dispatch(processAsyncCall(new Promise(/* ... */), /* ... */));

My understanding is that when a promise resolves, the then callback is called. But if the function resolves and there is no then callback at that time, the Promise is done/completed/dead.

Keep in mind that the example above is pretty straightforward, but in some cases the Promise is created elsewhere and it is passed down until it reaches the processAsyncCall function.

Answer 1

My understanding is that when a promise resolves, the then callback is called. But if the function resolves and there is no then callback at that time, the Promise is done/completed/dead.

That is incorrect. By definition, code cannot know when a promise will resolve, and requiring code to attach a callback before it resolves would put considerable constraints on promises and make them much less useful. No, you can attach a new callback at any time and it will be called:

const p = new Promise(r => {
    r('yay');
    setTimeout(() => p.then(console.log));
});

p.then(console.log);

The difference in your case is probably simply whether processAsyncCall expects a promise as argument or a function that returns a promise. Those are different types and must be handled differently, obviously.

Answer 2

I feel that Promise behaviour remains a little mysterious in your mind.

You can imagine a Promise as an object having 4 properties :

• a state,
• a value,
• a list of callback that will be called in case of success,
• a list of callback to be called if it failed.

The state always start at pending, and the code inside your promise is stacked to be called in the next execution loop as if you had called it with setImmediate.

The promise can only resolve or reject once and will remain in that state forever after that.

When a promise is resolved/rejected, its state changes to fulfilled or rejected, and the corresponding callbacks are called in order.

When you call then or catch on a Promise, if the state of the Promise is pending, the callback is added to the corresponding list. If the promise is already resolved (respectively rejected), the callback will be called in the next execution loop.

I hope it can help you understand what happens here.