async function without any await expressions 3
4const clientRouter = Router();
5
6clientRouter.get("/" , async (req , res) => { 7 res.send(req.query) 8}) 9
10export default clientRouterasync function without any await expressions 6 constructor(){
7 super(TestController, entity)
8 }
9 static async sayHi(){10 try{11 return entity.sayHello()12 }13 catch(error){14 return 'hubo error xd'15 }16 }17}
18
19export default TestControllerasync function without any await expressions52 }
53 }
54
55 async findError(error, res){56 return res.json({ msg: `El error es ${error.name}, cuyo mensaje es: ${error.message}` })57 }58}async function without any await expressions49 return res.json({message : "cerraste tu cuenta"})
50 }
51
52 async view(req, res){53 54 return res.json(client)55 }56
57 async validate(req, res){
58async function without any await expressions42
43 }
44
45 async logout(req, res){46 res.set('client', '', {47 expires: new Date(0), 48 })49 return res.json({message : "cerraste tu cuenta"})50 }51
52 async view(req, res){
53 A function that does not contain any await expressions should not be async (except for some edge cases
in TypeScript which are discussed below).
Asynchronous functions in JavaScript behave differently than other functions in two important ways:
- The return value is always a
Promise. - You can use the
awaitoperator inside them.
Functions are made async so that we can use the await operator inside them.
Consider this example:
async function fetchData(processDataItem) {
const response = await fetch(DATA_URL);
const data = await response.json();
return data.map(processDataItem);
}
Asynchronous functions that don't use await might be an unintentional result of refactoring.
Note: This issue ignores async generator functions.
Generators yield rather than return a value and async generators might yield all the values of another async generator without ever actually needing to use await.
In TypeScript, one might feel the need to make a function async to comply with type signatures defined by an interface.
Ideally, the code should be refactored to get rid of such restrictions, but sometimes that isn't feasible
(For example, when we are implementing an interface defined in a 3rd party library like Next.js).
This situation can easily be circumvented by returning the value with a call to Promise.resolve:
interface HasAsyncFunc {
getNum: () => Promise<number>
}
// Not recommended:
const o: HasAsyncFunc = {
async getNum() { return 1 }
}
// Recommended:
const o: HasAsyncFunc = {
// We only use `Promise.resolve` to adhere to the type
// of the surrounding object.
getNum() { return Promise.resolve(1) }
}
It is also advised to add a comment near the redundant promise to make the intent clear.
Bad Practice
async function fetchData(): string {
// `readFileSync` is a synchronous function that blocks
// the main thread, and thus does not need to be `await`ed
return fs.readFileSync("data.txt", "utf-8");
}
performAction(async () => { console.log("no awaits in here") });
Recommended
async function fetchDataAsync(): Promise<string> {
return await fs.readFile("data.txt", "utf-8")
}
performAction(async () => { await writeToFile(data) });
// Allow empty functions.
async function no_op() {}