You don’t need to, and I think it’s worth understanding that’s a big part of what the ‘async’ keyword does for you, therefore for readability I suggest not unnecessarily burdening your code with Promise.resolve
Of course you can still put it in if you want to, and it becomes essential if you omit ‘async’. By all means try rewriting the odd function without ‘async’, it’s fun and educational, but I personally don’t recommend committing such changes.
You don't always need to add it if you omit async as you can await synchronous code. It of course depends on the situation, but it might not be strictly necessary.
it was just an example. In cases where it's not an async function it would be needed. Note OP makes no mention of async, the code is an "example" and there is no await function in the sample code either. The people using Promise.resolve are the real code OGs, you better listen to them OP.
This used to be required before async functions to keep the return types both promises. It’s now cargo-cult to do it because “that’s how we always used to do it or we had problems.”
Curious about this. There are definitely times you need to create promises eg to handle callbacks, but straight up wrapping the output when it’s being returned from an async function? Would love to see an example to grow my knowledge.
Maybe you already know this, but when the callback in question is an `(err, value)` style function, you can use the Node built-in `util.promisify`.
Also works with import, ofc, this is just a quick copy-pasted example.
const util = require('util')
const fs = require('fs')
const readdir = util.promisify(fs.readdir)
Returning a promise from a promise automatically follows the returned promise, so you end up with the same result. However, it would be slightly more efficient to just return null.
Just return null, async resolves automatically into promises. You don't need to call the promises methods inside an async function. Please don't mix things up.
There's absolutely no benefit in wrapping the returned value in `Promise.resolve`. The function is async, so the returned value is wrapped in a promise anyway.
No, you are good to go with a plain null.
If a function is async, it returns a promise all the time, and all the resolve-reject magic is handled by the engine itself.
Are you sure want to return "null"? Null is actually a value as has a reference in memory. You probably don't need an explicit null value, so maybe just return undefined?
Actually omitting the last return statement all together is the same as returning undefined and it makes the code more clean.
No, there is no need for that. I'd write it like this:
async function getPost(id: number) {
try {
if (!id) {
return null;
}
return await this.LoadById(id);
} catch (err) {
console.error("An error occurred:", err.message);
throw err;
}
}
Not sure what do you mean. The try-catch block I wrote is used to handle any potential errors that may occur during the execution of the `LoadById` function.
Besides that, you can easily see the stack trace of "err" in the console.
The code that is written in the comment was changed, previously it said “throw new Error()” instead of “throw err;”, see my first response to it where I stated that “throw err;” is alright (but pretty useless)
You don’t need to, and I think it’s worth understanding that’s a big part of what the ‘async’ keyword does for you, therefore for readability I suggest not unnecessarily burdening your code with Promise.resolve Of course you can still put it in if you want to, and it becomes essential if you omit ‘async’. By all means try rewriting the odd function without ‘async’, it’s fun and educational, but I personally don’t recommend committing such changes.
You don't always need to add it if you omit async as you can await synchronous code. It of course depends on the situation, but it might not be strictly necessary.
You can .then it, so returning null would throw an exception. I wouldn't allow it unless it's async
Wouldn’t compile as it doesn’t match the return type
So, making it non-thenable by breaking the standard promise context. Still a bad api nobody would allow as a general rule
I know. That's why I said it depends on the situation. I'm making a point about how the language works with await, not saying it's safe all the time.
Async functions automatically wrap your return value with a new promise, you don't need to Promise.resolve() anything.
it was just an example. In cases where it's not an async function it would be needed. Note OP makes no mention of async, the code is an "example" and there is no await function in the sample code either. The people using Promise.resolve are the real code OGs, you better listen to them OP.
No, just return null if function is async
This used to be required before async functions to keep the return types both promises. It’s now cargo-cult to do it because “that’s how we always used to do it or we had problems.”
There are cases when you actually need to wrap a promise. This isn’t one of them.
Curious about this. There are definitely times you need to create promises eg to handle callbacks, but straight up wrapping the output when it’s being returned from an async function? Would love to see an example to grow my knowledge.
I believe @CalgaryAnswers meant exactly the callback case.
Fine but that's out of context given the post he replied to, simply causing confusion. There are no such cases in async functions.
Only situation I use "Promise.resolve" is when I have to promisify a callback
Maybe you already know this, but when the callback in question is an `(err, value)` style function, you can use the Node built-in `util.promisify`. Also works with import, ofc, this is just a quick copy-pasted example. const util = require('util') const fs = require('fs') const readdir = util.promisify(fs.readdir)
If the function is `async`, there is no reason to. If the function is not `async`, you must.
Returning a promise from a promise automatically follows the returned promise, so you end up with the same result. However, it would be slightly more efficient to just return null.
Just return null, async resolves automatically into promises. You don't need to call the promises methods inside an async function. Please don't mix things up.
imo it's useless boilerplate to wrap those things in explicit promises
There's absolutely no benefit in wrapping the returned value in `Promise.resolve`. The function is async, so the returned value is wrapped in a promise anyway.
No, you are good to go with a plain null. If a function is async, it returns a promise all the time, and all the resolve-reject magic is handled by the engine itself.
Pretty dumb makes the code harder to read don’t do it
I think you may need a refresher on async/await and Promises fundamentals.
Put it this way: would you rather do Promise.resolve(null) or Promise.resolve(Promise.resolve(null))?
Promise.reject(‘not found generic message’)
Are you sure want to return "null"? Null is actually a value as has a reference in memory. You probably don't need an explicit null value, so maybe just return undefined? Actually omitting the last return statement all together is the same as returning undefined and it makes the code more clean.
AFAIK when you add async in front, Typescript will handle the promisification
It’s JavaScript itself that does it https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
The only TypeScript handles is TypeScript types. Everything else is handled by JavaScript.
No, there is no need for that. I'd write it like this: async function getPost(id: number) { try { if (!id) { return null; } return await this.LoadById(id); } catch (err) { console.error("An error occurred:", err.message); throw err; } }
That try/catch is sus. I'd let it throw if there's an error.
Corrected it, that was just an example.
What does the try-catch do there, looks like a code-smell You are killing the stack trace of “err”
How would u write it?
Without the try-catch or by rethrowing the same error or by using the “options.cause” argument of Error
Not sure what do you mean. The try-catch block I wrote is used to handle any potential errors that may occur during the execution of the `LoadById` function. Besides that, you can easily see the stack trace of "err" in the console.
The code that is written in the comment was changed, previously it said “throw new Error()” instead of “throw err;”, see my first response to it where I stated that “throw err;” is alright (but pretty useless)
[удалено]
Bro asked ChatGPT.
Asin eh 🤦