Simplify code/examples

[balazsorban44]

I have seen this many places, like this example code:

signIn: async (user, account, profile) => {
  const isAllowedToSignIn = true
  if (isAllowedToSignIn) {
    return Promise.resolve(true)
  } else {
    // Return false to display a default error message
    return Promise.resolve(false)
    // You can also Reject this callback with an Error or with a URL:
    // return Promise.reject(new Error('error message')) // Redirect to error page
    // return Promise.reject('/path/to/redirect')        // Redirect to a URL
  }
}

When defining an async function, the returned value is automatically resolved, meaning one could refactor the above code. (Notice that throwing an Error would probably also feel more natural):

async signIn(user, account, profile) {
  const isAllowedToSignIn = true
  if (isAllowedToSignIn) {
    return true
  } else {
    // Return false to display a default error message
    return false
    // You can also Reject this callback with an Error or with a URL:
    // throw new Error('error message')) // Redirect to error page
    // return Promise.reject('/path/to/redirect')        // Redirect to a URL
  }
}

This may be only a personal preference, but I think it would also be easier to parse the code for newcomers. With the rise of "async/await", maybe there is lesser need of using Promises all-together. Any special reason I am unaware for using Promise.resolve() everywhere?

[iaincollins]

Any special reason I am unaware for using Promise.resolve() everywhere?

Good question! This has been asked before and yes, actually it is deliberate.

Internally, we try and avoid this in the library (and there are linter rules configured to discourage this) but the intent is that it's helpful re-enforcing to people that these functions are async and you can consequently do interesting things inside them.

The virtue of doing this is debatable, but a primary driver of the documentation is to reduce the amount of support overhead by making it easier for folks to see how they can solve problems they have - as support is where the majority of time is spent by contributors on this project at the moment.

[balazsorban44]

I would argue, that #897 just proved that this encourages using callbacks over async/await, which created the issue there, and made the user's code much more complicated than it needed to be (looks like to me that they were thinking they have to use Promise.#{reject,resolve} for it to work)

UPDATE.

The above mentioned issue's author just confirmed it in their last comment that Promise was misleading in the docs as a fairly new developer. I really recommend this to be visited and examples/code be simplified down to just async/await and simple returns without Promise.

[github-actions]

🎉 This issue has been resolved in version 3.2.0-canary.6 🎉

The release is available on:

• GitHub release
• npm package (@canary dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 3.3.0-canary.1 🎉

The release is available on:

• GitHub release
• npm package (@canary dist-tag)

Your semantic-release bot 📦🚀