Vlastné chybové stránky v Reakcii s GraphQL a chybovými hranicami

GitHub má úžasnú 500 chybovú stránku

Ak sa vám tento článok páči, prosím, podporte ma kontrolou Pull Reminders, Slack robota, ktorý posiela vášmu tímu automatické pripomenutie pre žiadosti o GitHub vytiahnutie.

Jednou z výziev, s ktorými som sa nedávno stretol pri práci s GraphQL a React bolo, ako zvládnuť chyby. Ako vývojári sme pravdepodobne implementovali predvolené 500, 404 a 403 stránok v serverových aplikáciách už predtým, ale zistiť, ako to urobiť s React a GraphQL, je zložité.

V tomto príspevku budem hovoriť o tom, ako náš tím pristupoval k tomuto problému, o konečnom riešení, ktoré sme implementovali, a zaujímavých poučeniach zo špecifikácie GraphQL.

Pozadie

Projekt, na ktorom som pracoval, bola pomerne typická aplikácia CRUD postavená v Reacte s použitím GraphQL, Apollo Client a express-graphQL. Chceli sme zvládnuť určité typy chýb - napríklad server je dole - zobrazením štandardnej chybové stránky používateľovi.

Našou prvotnou výzvou bolo zistiť najlepší spôsob, ako klientovi oznámiť chyby. GraphQL nepoužíva stavové kódy HTTP, napríklad 500, 400 a 403. Odpovede obsahujú pole chýb so zoznamom vecí, ktoré sa pokazili (viac informácií o chybách v špecifikáciách GraphQL).

Napríklad, ako vyzerá naša odpoveď GraphQL, keď sa niečo na serveri zlomí:

Pretože chybové hlásenia GraphQL vracajú stavový kód HTTP 200, jediným spôsobom, ako zistiť druh chyby, bolo skontrolovať pole chýb. Vyzeralo to ako zlý prístup, pretože vlastnosť chybové správy obsahovala výnimku vyvolanú na serveri. GraphQL špecifikuje, že hodnota správy je určená pre vývojárov, ale nešpecifikuje, či má byť hodnota správou čitateľnou pre človeka alebo niečím navrhnutým na programové spracovanie:

Každá chyba musí obsahovať záznam s kľúčovou správou s reťazcom opisom chyby určenej vývojárovi ako sprievodcu na pochopenie a opravu chyby.

Pridanie chybových kódov do odpovedí GraphQL

Na vyriešenie tohto problému sme pridali štandardizované chybové kódy k našim chybovým objektom, ktoré by mohli klienti použiť na programové identifikovanie chýb. Inšpirovalo sa to tým, ako rozhranie REST API spoločnosti Stripe vracia okrem správ čitateľných človekom aj kódy chybových reťazcov.

Rozhodli sme sa začať s tromi chybovými kódmi: authentication_error, resource_not_found a server_error.

Aby sme ich pridali do odpovedí GraphQL, prešli sme vlastnou funkciou formatError na expres-graphql, ktorá mapuje výnimky vyvolané na serveri na štandardné kódy, ktoré sa pridajú k odpovedi. GraphQL špecifikácia vo všeobecnosti odrádza od pridávania vlastností do chybových objektov, ale umožňuje to vkladaním týchto položiek do objektu rozšírenia.

Naše chyby odpovede GraphQL sa potom ľahko klasifikovali:

Aj keď sme vyvinuli vlastný spôsob pridávania kódov do odpovedí generovaných pomocou expresného grafu, zdá sa, že apollo-server ponúka podobné vstavané správanie.

Vykreslenie chybových stránok s hranicami React Error Error

Keď sme prišli na dobrý spôsob riešenia chýb na našom serveri, obrátili sme pozornosť na klienta.

V predvolenom nastavení sme chceli, aby naša aplikácia zobrazovala globálnu chybovú stránku (napríklad stránku so správou „oops niečo sa pokazilo“), kedykoľvek sme narazili na server_error, autorizačný_error alebo autorizačný_nabúdok. Chceli sme však tiež, aby flexibilita bola schopná zvládnuť chybu v konkrétnom komponente, ak sme to chceli.

Napríklad, ak používateľ niečo zadal do vyhľadávacieho panela a niečo sa pokazilo, chceli sme zobraziť chybové hlásenie v kontexte, namiesto toho, aby sme prešli na chybovú stránku.

Aby sme to dosiahli, najprv sme vytvorili komponent s názvom GraphqlErrorHandler, ktorý by sedel medzi komponentmi Query and Mutation apollo-klienta a ich deťmi, ktoré sa majú vykresliť. Táto súčasť skontrolovala chybové kódy v odpovedi a vyvolala výnimku, ak identifikovala kód, ktorý nás zaujíma:

Aby sme mohli používať GraphqlErrorHandler, zabalili sme komponenty dopytov a mutácií apollo-klienta:

Náš komponent komponentu potom namiesto priameho prístupu k reakcii-apollo použil náš vlastný komponent dopytu:

Keď teraz naša aplikácia React hádzala výnimky, keď server vrátil chyby, chceli sme tieto výnimky vyriešiť a mapovať na vhodné správanie.

Od začiatku si pamätajte, že naším cieľom bolo predvolene zobrazovať stránky s globálnymi chybami (napríklad stránka so správou „oops niečo sa pokazilo“), ale napriek tomu máme flexibilitu na to, aby sme mohli chybu lokálne spracovať v ľubovoľnom komponente, ak sme si to želali.

Hranice chýb reakcií poskytujú fantastický spôsob, ako to urobiť. Hranice chýb sú komponenty React, ktoré dokážu zachytiť chyby JavaScriptu kdekoľvek v ich podradenom strome komponentov, takže ich môžete zvládnuť pomocou vlastného správania.

Vytvorili sme hranicu chýb s názvom GraphqlErrorBoundary, ktorá zachytí všetky výnimky súvisiace so serverom a zobrazí príslušnú chybovú stránku:

Hranicu chyby používame ako obal pre všetky komponenty našej aplikácie:

Hranice chýb môžu byť použité hlbšie v strome komponentov, ak chceme namiesto vykreslenia chybové stránky spracovať chyby v komponente.

Napríklad, ako by to vyzeralo, keby sme chceli vlastné správanie pri riešení chýb v našej komponente z predchádzajúceho obdobia:

Zabaliť

GraphQL je stále relatívne nový a spracovanie chýb je bežnou výzvou, do ktorej vývojári pravdepodobne narazia. Použitím štandardizovaných kódov chýb v našich odpovediach GraphQL dokážeme chyby klientom komunikovať užitočným a intuitívnym spôsobom. Hranice chýb v našich aplikáciách React poskytujú skvelý spôsob, ako štandardizovať správanie pri riešení chýb našej aplikácie a zároveň mať flexibilitu, keď ju potrebujeme.