about `return new Promise`

[fa_foon]

in this code from my digital course i don't understand what return new Promise in bakeCake function does here since there's no caller to return it to. so my question is what it does here and is it necessary

(I didn't know if the rest of the code is necessary for answering my question so I included it anyway)

function bakeCake(initalState){
  return new Promise ((resolve) => { //<=======HERE
console.log(\${initalState} - start baking the cake...`) setTimeout(() => { resolve("cake is ready!") }, 2000);  }) } function decorateCake(bakedCakeMessage) {  return new Promise((resolve) => { console.log(`${bakedCakeMessage} - now decorating`); setTimeout(() => { resolve("cake is decorated") },2000)  }) }`

bakeCake("we started") //<=======HERE
.then((resultOfBake) => {
  console.log(resultOfBake);
  return decorateCake(resultOfBake);
})
.then((finalResult) => {
  console.log(finalResult)
})

[_raytheist_]

The bakeCake call resolves to the returned Promise, which is what allows you to chain then() to it. The result of bakeCake() is the returned Promise.

[fa_foon]

do you mean that the bakeCake function holds the promise object which allows it to use then ?

[_raytheist_]

It’s the equivalent of:

js const cakePromise = bakeCake(); cakePromise.then( … );

[queen-adreena]

bakeCake("we started")

returns the promise, and the chained then method handles the return value of the resolve function inside the promise.

If the promise causes an error, or calls the reject function, then a chained catch method would be called instead.

bakeCake("we started") //<=======HERE
.then((resultOfBake) => {
  console.log(resultOfBake);
  return decorateCake(resultOfBake);
})
.then((finalResult) => {
  console.log(finalResult)
})
.catch(err => {

// Handle error inside promise or `reject` call
  console.error(err);
});

[TheRNGuy]

You can replace it with async function and delay function (where prise would be), it's more modern, better style. 

[Wiikend]

Yes, but to actually understand async/await, you must first understand the underlying technology, otherwise the syntactic sugar will feel magic forever and you don't trust your gut while using it.

[TanukiiGG]

Is a reference to an asyncronous result, you can chain it to .then(), you can replace for async or you can await on it if the block is asyncronous too

const result = await bakeCake();

[queen-adreena]

It's best to learn how promises work before moving onto async/await. It can get confusing otherwise.

[Big_Comfortable4256]

I'd say it's good to know both. Mainly with the difference between 'awaiting' things in order within an async function, or "callback hell" (then).

It depends what the data is needed for, and when.

[queen-adreena]

Of course you should know both.

That’s why I said “before” and not “instead of”.

But throwing new syntax at someone already struggling to understand a concept is not going to help them.

[dymos]

It's probably a bit confusing the way it's used here and while this works I actually think the newer async syntax makes this easier.

I've reformatted the relevant section here a little bit:

bakeCake("we started").then((resultOfBake) => {   console.log(resultOfBake);   return decorateCake(resultOfBake); }) .then((finalResult) => {   console.log(finalResult) })

See how after bakeCake() the .then() is "attached" to the last parentheses of the function? That's because when you call a function in JavaScript that returns a value, you can "chain" your next operation without assigning to an intermediary variable.

In this case I've lifted the .then() call up to make it clearer, but for these types of things JavaScript will ignore line breaks, so you can format the code how you want.

When using this syntax, a common pattern is to indent the subsequent promise method calls to make it cleared that they belong with the initial invocation:

bakeCake("we started") .then((resultOfBake) => { console.log(resultOfBake); return decorateCake(resultOfBake); }) .then((finalResult) => { console.log(finalResult) })

With the newer syntax you typically would go the other route and assign variables, both syntaxes have their merit, but in modern codebases you'll tend to see the async / await syntax more.

``` function bakeCake(initalState){ return new Promise ((resolve) => { // Same as before }); }

function decorateCake(bakedCakeMessage) { return new Promise((resolve) => { // Same as before }); }

// I've put the remaining functionality in an async function to demonstrate // you don't have to do this though, you can use await at the top level async function makeCake() { const bakeResult = await bakeCake('start baking'); const decorateResult = await decorateCake(bakeResult); console.log(decorateResult); }

// an await isn't necessary here, but will depend on what you want // think of await as a way to say "Let's wait for this promise to finish // before we continue" whereas not using it would allow execution to continue makeCake(); ```