Tao-ul promisiunilor
cu puțin mai multă experiență și înțelegere a promisiunilor și a legilor monadice care guvernează utilizarea acesteia, nu am fi petrecut atât de mult timp lucrând la refactorul acestei bucăți de cod.
în JavaScript, codul asincron poate fi gestionat prin promisiuni, care sunt monadele de continuare ale JavaScript. Cel mai important lucru în acest caz despre promisiunile de a fi o monadă este că următoarea lege este adevărată:
Promise.resolve(Promise.resolve(x)) === Promise.resolve(x).
și mai important decât cel de mai sus, acesta este valabil și pentru orice valoare x:
Promise.resolve(Promise.reject(x)) === Promise.reject(Promise.resolve(x)) === Promise.reject(x).
această regulă magică de mai sus este ceea ce mi-a salvat o putere de gândire la sfârșitul zilei. Acest lucru a însemnat că am putut trata acele erori de îndată ce s-au întâmplat, în interiorul propriilor funcții, stând departe de acea nebunie cu lanț lung. Răspunsul a fost întotdeauna acolo holbându-se la mine, pur și simplu nu am putut vedea. Acum văd, și e frumos.
bună, adevărată promisiune
aceasta însemna că aș putea avea pur și simplu funcția saveapplication ca aceasta, de exemplu:
function saveApplication() {
return makeApiCall().catch((err) => Promise.reject('basic'));
}
the .catch block înseamnă că gestionăm o eroare la pasul de bază al formularului, deoarece apelul saveApplication este legat de Pasul formularului numit basic. Acest lucru ne-a condus la frumoasa bucată de cod de mai jos:
saveApplication()
.then(uploadImages)
.then(saveService)
.then(savePricingInfo)
.then(savePaymentInfo)
.then(gotoMainPage)
.catch((step) => {
setErrorState();
multiStepManager.go(step);
});
am avut doar pentru a schimba o singură linie a lanțului de promisiune, acum că toate funcțiile din interiorul .apoi blocuri returnează o promisiune care respinge deja la Pasul corespunzător.
dar dacă s-ar întâmpla alte tipuri de erori, care nu au fost gestionate de capturile interioare?Ei bine, care ar putea fi rezolvate cu ușurință prin punerea în aplicare tipuri de erori personalizate, și separarea evaluarea diferitelor tipuri de erori în interiorul nostru principal .bloc de captură. Astfel:
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
}
});
în acest caz, principalul .bloc de captură se ocupă numai erori de tip StepError. Alte tipuri de erori sunt pur și simplu aruncate, nu respinse, astfel încât să poată fi tratate în mod corespunzător de către aplicație sau browser.
același principiu poate și trebuie extins pentru a gestiona anumite tipuri de erori, cum ar fi diferite stări HTTP.