Le Tao des Promesses
Avec un peu plus d’expérience et de compréhension des Promesses et des lois monadiques qui régissent son utilisation, nous n’aurions pas passé autant de temps à travailler sur le refacteur de ce morceau de code.
En JavaScript, le code asynchrone peut être géré via des promesses, qui sont les monades de continuation de JavaScript. La chose la plus importante dans ce cas à propos des promesses étant une monade est que la loi suivante est vraie:
Promise.resolve(Promise.resolve(x)) === Promise.resolve(x).
Et plus importante que celle ci-dessus, celle-ci vaut également pour toute valeur x:
Promise.resolve(Promise.reject(x)) === Promise.reject(Promise.resolve(x)) === Promise.reject(x).
Cette règle magique ci-dessus est ce qui m’a sauvé un peu de pouvoir de pensée à la fin de la journée. Cela signifiait que je pouvais traiter ces erreurs dès qu’elles se produisaient, à l’intérieur de leurs propres fonctions, en restant à l’écart de cette folie à longue chaîne. La réponse était toujours là à me regarder, je ne pouvais tout simplement pas la voir. Maintenant, je vois, et c’est magnifique.
Cela signifiait que je pouvais simplement avoir la fonction saveApplication comme celle-ci, par exemple:
function saveApplication() {
return makeApiCall().catch((err) => Promise.reject('basic'));
}
Le.le bloc catch signifie que nous traitons une erreur sur l’étape de base du formulaire, car l’appel saveApplication est lié à l’étape du formulaire appelée basic. Cela nous a conduit au beau morceau de code ci-dessous:
saveApplication()
.then(uploadImages)
.then(saveService)
.then(savePricingInfo)
.then(savePaymentInfo)
.then(gotoMainPage)
.catch((step) => {
setErrorState();
multiStepManager.go(step);
});
Nous n’avons eu qu’à changer une seule ligne de la chaîne de promesses, maintenant que toutes les fonctions à l’intérieur du.ensuite, blocks renvoie une promesse qui est déjà rejetée à l’étape correspondante.
Mais que se passe-t-il si d’autres types d’erreurs se produisent, qui n’ont pas été gérées par les captures internes?
Eh bien, cela pourrait être facilement résolu en implémentant des types d’erreurs personnalisés et en séparant l’évaluation des différents types d’erreurs dans notre main.bloc de capture. Comme ceci:
function saveApplication() {
return makeApiCall().catch((err) => Promise.reject(new StepError('basic')));
}//
saveApplication()
.then(uploadImages)
.then(saveService)
.then(savePricingInfo)
.then(savePaymentInfo)
.then(gotoMainPage)
.catch((step) => {
if(err instanceof StepError) {
setErrorState();
multiStepManager.go(step);
}
else {
// handle other types of errors
}
});
Dans ce cas, le principal.le bloc catch ne gère que les erreurs de type StepError. D’autres types d’erreurs sont simplement rejetés, non rejetés, afin qu’ils puissent être traités en conséquence par l’application ou le navigateur.
Le même principe peut et doit être étendu pour gérer des types d’erreurs spécifiques, tels que différents statuts HTTP.