J'essaie d'implémenter une route api dans mon serveur nodejs appelée 'get_stock_data'. Cependant, une fois cette route utilisée, le serveur appelle une autre bibliothèque pour récupérer les données, et en retour les renvoie. Actuellement, si j'essaye d'enregistrer la réponse, il dit Promise <>. Je ne sais pas comment ajouter .then () et attendre la promesse.
app.get('/get_stock_data', (req, res) => {
res.header("Access-Control-Allow-Origin", "*");
const stockName = JSON.parse(req.query.data).stockName;
res.send(get_stock_data_request(stockName));
}
);
Le get_stock_data_request est une fonction async / wait qui appelle les bibliothèques d'API sur nodejs.
3 Réponses :
Utilisez simplement then and catch pour traiter les réponses régulières et d'erreur de get_stock_data_request
app.get('/get_stock_data', (req, res) => {
res.header("Access-Control-Allow-Origin", "*");
try {
const stockName = JSON.parse(req.query.data).stockName;
get_stock_data_request(stockName)
.then(result => res.send(result))
.catch(err => res.status(400).send(err));
} catch (err) {
res.status(400).send('Error parsing query parameters')
}
}
);
Pour être complet, vous devriez avoir un try/catch autour de l'appel JSON.parse() et envoyer une erreur si cela lève. C'est un cas que la réponse de Naren utilisant async couvre déjà.
JSON.parse est synchrone afin que l'erreur puisse être interceptée par un gestionnaire d'erreur global
Euh, ce n'est pas une bonne stratégie. Un gestionnaire de requêtes doit gérer ses propres erreurs et envoyer sa propre réponse d'erreur en cas d'erreur. Et, il devrait protéger contre les erreurs dans les données fournies par l'utilisateur, ce qui est JSON.parse(req.query.data) . J'ai fait une suggestion sur la façon dont vous pourriez améliorer votre réponse et j'espérais que vous en saisiriez l'occasion.
Essayez peut-être d'ajouter await pour que cela soit await res.send(get_stock_data_request(stockName)); sinon, essayez d'ajouter res.send(await get_stock_data_request(stockName));
Vous pouvez également utiliser async/await pour le gestionnaire de requêtes (it's also just normal function ;-) .
Essayez comme ceci:
app.get('/get_stock_data', async (req, res) => {
try {
res.header("Access-Control-Allow-Origin", "*");
const stockName = JSON.parse(req.query.data).stockName;
const response = await get_stock_data_request(stockName)
return res.json(response) // If you get json as response otherwise use `res.send`
} catch(err) {
res.status(400).json(err) or .send(err)
}
);
Express.js prend-il déjà en charge les gestionnaires asynchrones? J'en doute. Vous devriez l'envelopper en utilisant quelque chose comme le package express-async-wrap
Je veux dire que si nous avons un gestionnaire d'erreur global, nous n'attrapons pas d'exception sans cet emballage spécial
Non, vous n'avez besoin d'aucun module, Node js prend en charge async / await au-dessus du nœud 7.6
Il le prend en charge en tant que mots-clés, mais cela ne signifie pas qu'express.js prend en charge les middlewares asynchrones lui-même.
Ouais! Je pense que vous avez raison, les middlewares Express ne prennent pas en charge async wait
Mais, si vous voulez faire des trucs asynchrones / en attente dans les middlewares, vous pouvez essayer quelque chose comme ça
@Anatoly - Vous êtes parfaitement libre de déclarer un gestionnaire d'itinéraire express comme async . Express lui-même ignorera la promesse renvoyée par ce gestionnaire, mais si vous gérez tout vous-même à l'intérieur du gestionnaire de route (ce qui est généralement de votre responsabilité de toute façon), alors vous pouvez utiliser des gestionnaires de route async et pouvez donc utiliser await intérieur d'eux très bien - Je fais cela tout le temps dans mes gestionnaires d'itinéraire.
Je suppose que dans un certain gestionnaire d'itinéraire, vous ne devez gérer que les erreurs attendues lors de l'analyse / traitement des entrées, de la vérification des droits d'accès, de certaines validations, etc. Si c'est quelque chose avec une connexion à la base de données (par exemple), il doit être géré par un gestionnaire d'erreurs global qui envoie 500 codes et une description d'erreur au client tout en enregistrant tous les détails de l'erreur dans son propre journal.
Pour que nous puissions voir tout le problème, il serait préférable que vous
get_stock_data_request()le code deget_stock_data_request()au cas où il y aurait des problèmes dans sa conception asynchrone. Bien que vous disiez qu'il estasync, cela ne garantit pas une conception asynchrone appropriée.