Artikuj të ndryshëm në internet kanë diskutuar tashmë përfitimet e përdorimit të react-query. Lehtësia e përdorimit të useQuery/useMutation, d.m.th., në thelb me një linjë, për të marrë akses në gjendjen e ngarkimit, marrjen ose gabimin dhe të dhënat e përgjigjes, tashmë është përsëritur vazhdimisht. Por veçoritë më të avancuara dhe të veçanta pothuajse nuk janë diskutuar. Kështu që ja ku jam, duke u thelluar në disa nga veçoritë e botës së pyetjeve të reagimit.

Unë do t'ju jap një shembull të një aplikacioni të thjeshtë të listës së detyrave, ku shfaqet një listë e detyrave. Dhe kur përdoruesi dëshiron të krijojë një detyrë të re, hapet një formë modale. Pas krijimit të suksesshëm të detyrave, lista e detyrave do të rikthehet. Në listën e detyrave, nëse përdoruesi klikon në një detyrë, ai do të shkojë në një faqe të re, ku do të shfaqen detajet që korrespondojnë me atë detyrë.

1. onSucces & oneError

Të dyja useQuery dhe useMutation mbështesin opsione të ndryshme konfigurimi. Dy prej tyre janë parametra onSuccess dhe onError, që pranojnë një funksion. Këto dy opsione mund të jenë të dobishme, veçanërisht nëse dëshirojmë të kryejmë disa logjikë të paraqitjes së të dhënave. Në shembullin e listës së detyrave, nëse duam të hedhim çipa mesazhi suksesi ose gabimi, që nuk janë domosdoshmërisht një komponent, përdorimi mund t'i përdorë këto. (Në rast se nevojitet rendering komponent, ne jemi më mirë me isSuccess ose isError). Në thelb kjo mund të veprojë si funksioni i kthimit të thirrjes brenda.then që përdorim në marrjen e api. Rasti më i mirë i përdorimit do të ishte dërgimi i një gjendje redux. Mund të bëhet edhe këtu, pa u hutuar rreth useEffect.

2. Pavlefshmëria e pyetjes

Në shembullin e listës së detyrave, siç kemi diskutuar, ne do të dëshironim të rimarrnim listën e të gjitha detyrave, në krijimin e suksesshëm të një detyre. Pra, këtu vjen magjia e anulimit të pyetjes. Duhet të përdorim funksionin e diskutuar më parë, onSuccess. Në funksion ne mund të përdorim queryClient invalidation për të zhvlerësuar, d.m.th. të kërkojmë react-query për të rimarrë një ose më shumë pyetje/pyetje.

Në aplikacionin tonë të detyrave, kur detyra jonë e krijimit të jetë e suksesshme, ne do të zhvlerësonim pyetjen që po merr listën tonë të të gjitha detyrave.

3. Riprovimet e pyetjes

Kjo mund të jetë e vogël, por mund të jetë e dobishme kur e kërkon situata. Pyetja React vjen me disa vlera të paracaktuara të parakonfiguruara që korrespondojnë me çdo opsion konfigurimi. Për shembull, koha e cache-it është 5 minuta dhe koha e vjetëruar është 0. Pra, një nga opsionet e shumta, është opsioni retry. Vlera e tij e paracaktuar është 3. Kjo do të thotë nëse një pyetje nuk është e suksesshme në marrjen e pyetjes në përpjekjen e parë, ai do të vazhdojë të provojë 3 herë përpara se të deklarojë isError të jetë e vërtetë. Në disa raste, ju mund të mos e dëshironi atë sjellje. Ju gjithmonë mund ta ndryshoni atë në një numër tjetër që tregon numrin e riprovave që dëshironi të ndodhin. Një mënyrë tjetër është, riprovimi gjithashtu pranon të vërtetën dhe false si vlerë gjithashtu. Cfare do te thote ajo? Nëse riprovimi është i vërtetë, atëherë pyetja e reagimit do ta marrë pyetjen derisa të jetë e suksesshme dhe nëse është e gabuar, atëherë asnjë riprovim nuk ndodh pas ndonjë përpjekjeje të pasuksesshme.

Të gjitha këto opsione mund të ndryshohen sipas bazës së pyetjes. Por ju mund të dëshironi të deklaroni opsionet tuaja të konfigurimit për të gjitha pyetjet (nëse nuk specifikoni ndryshe në ndonjë pyetje të veçantë). Atëherë duhet të konsideroni ta bëni këtë në klientin e pyetjes.

4. Aktivizimi i pyetjes me kusht

Në disa raste, mund të dëshironi që një pyetje të ekzekutohet vetëm nëse plotësohet një kusht. useQuery dhe të gjitha të mirat e tjera të pyetjes së reagimit, duke qenë grepa, nuk mund të përdoren drejtpërdrejt në ndonjë deklaratë if-else, pasi kjo do të thyente rregullin bazë të grepave të reagimit. Për këto lloj skenarësh, react-query vjen me një opsion të quajtur enabled. Ne gjithmonë mund t'i kodojmë fort ato që të jenë të vërteta ose false, por ajo ku me të vërtetë shkëlqen është kur kalohet një ndryshore. Tani sipas atij ndryshimi të vlerës së ndryshores, pyetja do të aktivizohej ose çaktivizohej. Sa e lezetshme është kjo!

Për shembull, në aplikacionin tonë të listës së detyrave, kur përdoruesi shkon te detyra individuale, todo_id kalohet si param në url (duke përdorur react-router ose bibliotekë tjetër të rrugëtimit). Dhe sipas todo_id, detajet janë marrë. Tani do të dëshironim të merrnim pyetjen, vetëm nëse parametri nuk është null. Ne mund ta bëjmë në këtë mënyrë atëherë -

5. Ganpa të personalizuara për Query

Është më shumë një opinion personal sesa të jetë një veçori specifike e pyetjeve të reagimit. Pra, nëse ju duhet të personalizoni sjelljen përtej opsioneve të parakonfiguruara ose duhet të përdorni opsionet onSuccess ose onError, shumë shpejt mund të përfundoni me diçka të tillë. Disa mund të preferojnë që dikush të mund të shohë menjëherë se çfarë po ndodh në pyetje. Por nëse ndonjëherë ju duhet të përdorni të njëjtin pyetje në disa komponentë, mund të dëshironi të krijoni fiksimin tuaj të personalizuar të mbështjellë rreth të gjithë logjikës së pyetjes reaguese. Dhe ju siguroj, nuk është ndonjë xhuxhutsu i nivelit të lartë. Nëse marrim parasysh shembullin e mëparshëm, do të ishte kështu:

Disa këshilla profesionale

  1. Nëse mendoni të shkruani grepa të personalizuara, mund të konsideroni gjithashtu deklarimin e një variabli ku ne thjesht i mbajmë ato të dhëna ose nëse keni nevojë për kodin e statusit për ndonjë arsye, atëherë mund ta abstraktoni edhe këtu dhe të kaloni si vlerë të vetme dhe të krijoni të dhënat që na duhen për të hartuar ose ndërmarrë veprime të tjera. Një variabël i përcaktuar mirë ka më shumë kuptim sesa të dhënat gjenerike.

2. Në rast të riemërtimit të të dhënave si diçka tjetër, mund ta bëni atë direkt edhe në react-query. Dhe jo vetëm të dhënat, mund të riemërtoni isLoading ose isError në diçka tjetër gjithashtu. Është veçanërisht e nevojshme nëse keni nevojë të përdorni dy ose më shumë pyetje në një komponent.

3. Ju mund të përdorni rrugët api si emra pyetjesh. Do të ketë shumë kuptim nëse abstraktoni funksionin tuaj të pyetjes diku tjetër. Mund të ndihmojë gjithashtu, nëse zbuloni se keni nevojë për të hyrë në atë pyetje të veçantë, që mendoni se e keni përdorur tashmë në ndonjë komponent. Dhe tani do të dëshironit ta përdorni në ndonjë komponent tjetër. Duke emërtuar në atë mënyrë, do të largoheni lehtësisht nga gjetja e emrit të asaj pyetjeje të veçantë. Në fund të fundit, emrat e pyetjeve janë thelbësore për të shfrytëzuar në mënyrë të frytshme përfitimet e pyetjes reaguese (p.sh., pavlefshmëria e pyetjes). Këtë stil e kam ndjekur gjatë gjithë artikullit.

4. Nëse përdorni grepa të personalizuara, mund t'i mbani ato në skedarë të veçantë sipas rrugës kryesore të tyre. Dhe duke i mbajtur të gjitha brenda vetë dosjes së shërbimeve, e njëjta strukturë që mund të përdorni tashmë me axios.

src
 — components
 — pages
 — services
  — todo.js
  — user.js

Nuk është menduar të jetë diçka shteruese. Vetëm disa, që po i përdor çdo ditë.

Disa nga pjesët e fundit kanë qenë thjesht hakime personale, me të cilat mund të mos jeni dakord ose unë mund të bëj gabim. Ju lutem mos ngurroni të më tregoni kështu.

Më shumë përmbajtje në PlainEnglish.io. Regjistrohu për buletinin tonë javor falas. Na ndiqni në Twitter dhe LinkedIn. Bashkohuni me Mosmarrëveshjet në komunitet.