Mais cela ne semble pas être la bonne façon de procéder.
C'est en effet la bonne façon de le faire (ou du moins une bonne façon de le faire). C'est un aspect clé des promesses, c'est un pipeline et les données peuvent être massées par les différents gestionnaires du pipeline.
Exemple:
const promises = [
new Promise(resolve => setTimeout(resolve, 0, 1)),
new Promise(resolve => setTimeout(resolve, 0, 2))
];
Promise.all(promises)
.then(data => {
console.log("First handler", data);
return data.map(entry => entry * 10);
})
.then(data => {
console.log("Second handler", data);
});
( catch
gestionnaire omis par souci de concision. Dans le code de production, toujours soit propager la promesse, soit gérer le rejet.)
Le résultat que nous en voyons est:
Premier gestionnaire [1,2]
Second handler [10,20]
... parce que le premier gestionnaire obtient la résolution des deux promesses ( 1
et 2
) sous forme de tableau, puis crée un nouveau tableau avec chacune de celles multipliées par 10 et le renvoie. Le deuxième gestionnaire obtient ce que le premier gestionnaire a renvoyé.
Si le travail supplémentaire que vous effectuez est synchrone, vous pouvez également le placer dans le premier gestionnaire:
Exemple:
const promises = [
new Promise(resolve => setTimeout(resolve, 0, 1)),
new Promise(resolve => setTimeout(resolve, 0, 2))
];
Promise.all(promises)
.then(data => {
console.log("Initial data", data);
data = data.map(entry => entry * 10);
console.log("Updated data", data);
return data;
});
... mais s'il est asynchrone, vous ne voudrez pas le faire car il finit par être imbriqué, et l'imbrication peut rapidement devenir incontrôlable.
reject
une valeur après laPromise
fonction initiale ? Ou est-ce que lancer une erreur n'importe où dans la chaîne vous amènera au.catch()
? Si tel est le cas, quel est l'intérêtreject
en premier lieu? Pourquoi ne pas simplement lancer une erreur? Merci encore,