0

Basically what you see me doing here is "asyncing" a promise that I'm just creating.

Is that some unadvisable, anti-pattern, fatal flow, or silly way to write a promise? If so, why?

function returnSomething(name) {

  return new Promise(async (resolve, reject) => {

    try {

       //some dealings....
 
       const somethingElse = await returnSomethingElse();

       //do some stuff with 'somethingElse'

       resolve(somethingElse);
    
    } catch(error) {

       //some dealings....

       reject(error);
       return;

    }

  });

}

The temptation to do this is basically very easy to explain. I want to avoid the .then().then().then() hell if I return a promise as a result from a promise.

I also wanted to avoid working with something like this:

function returnSomething(name) {

  return new Promise((resolve, reject) => {

       //some dealings....
 
       returnSomethingElse().then((somethingElse) => { 

          //do some stuff with 'somethingElse'

          resolve(somethingElse); 

       }).error((error) => {

          //some dealings....

          reject(error);
          return;
       });
    }

  });

}

Thanks in advance.

Jerome Guenon
  • 19
  • 5
  • 1
    `async function() {...}` declares that `function() { ... }` returns a promise, so yeah, kind of silly. Looks like you're falling into the ["Promise constructor anti-pattern"](https://stackoverflow.com/q/23803743/215552). Seems like you could just slap `return` in front of `returnSomethingElse()` in your second example... – Heretic Monkey Feb 22 '22 at 20:58
  • 1
    Just ditch the promise constructor since `returnSomethingElse` already returns a promise for you. Have your regular function `returnSomething` be async and then do your `await` and additional processing work in there. – CRice Feb 22 '22 at 21:00
  • why not just make returnSomething a async function? There is no JS police that will come after you for doing this but its not very readable/maintanable code. I would recommend to not mixing Promise and async – BrendanMullins Feb 22 '22 at 21:01
  • It's difficult to answer because it's a contrived example. `// some dealings....` and `// do some stuff with 'somethingElse'` could be anything. But, generally, I would go with @CRice suggestion as the function seems an unnecessary step. – Andy Feb 22 '22 at 21:07
  • 1
    "*I want to avoid the .then().then().then() hell*" erm, [that's pretty reasonable way to use promises](https://stackoverflow.com/questions/22539815/arent-promises-just-callbacks). They were designed for way easier interface via `.then()` chaining. You're just reimplementing [callback hell](http://callbackhell.com/). – VLAZ Feb 22 '22 at 21:09
  • "*if I return a promise as a result from a promise.*" wait I didn't read this part. Here is the fatal flaw of your logic - *promises cannot return nested promises*. They automatically flatten. If you return a promise, you're still dealing with one level of promise at the end, you don't have to "unwrap it twice". `Promise.resolve(Promise.resolve(42))` handles exactly the same as `Promise.resolve(42)` - adding `.then(x => console.log(x))` is going to print the same value. Same with using `await` - you still get `42` not a promise. – VLAZ Feb 22 '22 at 21:13
  • 1
    "then().then().then() hell" - it's not. But any way, consider studying how raw promises and async..await are related. The latter is sugar syntax for the former and intended exactly to make then-then code neater. "If so, why?" - it results in unnecessarily convoluted and buggy code that is hard to read, write and maintain. That's also a definition for most antipatterns around. – Estus Flask Feb 22 '22 at 23:08

0 Answers0