Hitchhiker's Guide to React Router v4: [match, placering, historie] - dine bedste venner!

Hej! Velkommen til Hitchhiker's Guide to React Router v4, del II!

Nu hvor vi har sat bolden til at køre med vores første lille app, lad os fokusere på dine tre rejsekammerater: match , placering og historie .

Hvad sker der, hvis du kommer ind i din Home Component-kode og lægger en console.log der for at kontrollere rekvisitterne?

Router introducerer i din komponent følgende objekter:

Wow! Hvor kommer det fra? ?

Nå, hver visning, komponent eller hvad der er pakket af Router har disse objekter. gør sit job som en Higher Order-komponent og indpakker dine komponenter eller synspunkter og injicerer disse tre objekter som rekvisitter inde i dem.

Så ... hvorfor er de der, og hvad kan jeg bruge dem til? ?

De bliver dine bedste venner! Stol på mig! ?

Match

Den kamp objekt indeholder oplysninger om, hvordan en matchede webadressen.

  • params : (objekt), nøgle / værdipar parset fra URL'en, der svarer til stiens dynamiske segmenter
  • isExact : (boolsk), sandt, hvis hele URL'en blev matchet (ingen efterfølgende tegn)
  • sti : (streng), det stingmønster, der bruges til at matche. Nyttig til opbygning af indlejrede ruter . Vi kigger på dette senere i en af ​​de næste artikler.
  • url : (streng), den matchede del af URL'en. Nyttig til opbygning af indlejrede links.

Så i Hjem komponent vi har denne kamp objekt:

isExact er sandt, fordi hele URL'en blev matchet, params- objektet er tomt, fordi vi ikke sendte noget ind i det, stien og url- nøgleværdierne er ens, hvilket bekræfter, at isExact er sandt.

Lad os nu se på TopicList View :

Intet nyt indtil nu, samme historie som i Home View , der viser stien og url'en til TopicList .

Men hvad hvis vi kigger på TopicDetails ?

Okay, hvad har vi her?

isExact er fortsat sandt, fordi hele URL'en blev matchet. params- objekt bringer topicId- info, der blev sendt til komponenten.

Vær opmærksom på, hvordan topicId er en variabel.

Men hvor antager det Topic1- værdien?

Enkelt, du påberåber det på en eksplicit måde i TopicList Links .

Tjek, hvordan vi har brugt match for TopicList til at kende dens URL.

Dette link kunne være dynamisk . Senere vi vil gøre et eksempel, hvor du Link til en relativ sti, hvor du ikke ved tidligere, hvis det er Topic1 eller Topic3520 .

Men…

I hvilken situation er isExact false?

Nå ... lad mig give dig et eksempel:

I denne situation har vi introduceret / HelloWorldSection i browserens URL.

Hvad der sker er, at routeren ikke kender den fulde sti til HelloWorldSection, så den dirigerer dig op, hvor den kender vejen.

isExact viser falsk, der fortæller dig nøjagtigt, at " hele webadressen ikke blev matchet ".

Dette er meget nyttigt, som du vil se, så snart du begynder at lave spa med RRv4!

Bare for at afslutte vores tilgang til match, tjek dette ud:

Vi har brugt match.params.topicId til at udskrive vores emnes navn på skærmen.

Dette er en af ​​de mest almindelige anvendelser til match .

Selvfølgelig har den en lang række applikationer. Antag, at vi skal hente en API med denne topicId- information. ?

Beliggenhed

Den placering objekt repræsenterer hvor app er nu, hvor du vil have det til at gå, eller endda hvor det var.

Det findes også på history.location, men du bør ikke bruge det, fordi det kan ændres.

Et placeringsobjekt muteres aldrig, så du kan bruge det i livscykluskrogene til at bestemme, hvornår navigationen sker. Dette er virkelig nyttigt til dataindsamling eller DOM- bivirkninger.

Lad os console.log (placering) inde i Home View :

Lad os ikke dybe meget og fortsætte med dens enkle funktionalitet.

Du har stienavnøglen / værdien.

Du kan f.eks. Bruge det til at kontrollere, om stienavn er ændret:

Du kan eller til det. Du kan lave en history.push eller history.replace som vi vil se senere.

Du kan oprette et brugerdefineret objekt og bruge det

  • history.push (locationX)

Du kan også videregive det til og komponenter.

Dette forhindrer dem i at bruge den faktiske placering i routerens tilstand. Måske vil du narre en komponent til at gengive et andet sted end den rigtige?

Nok af placeringen nu ...

Lad os gå til historien !

Historie

Den historie objekt giver dig mulighed for at styre og håndtere browserens historik inde i dine synspunkter eller komponenter.

  • længde : (nummer), antallet af poster i historikstakken
  • handling : (streng), den aktuelle handling (PUSH, REPLACE eller POP)
  • placering : (objekt), den aktuelle placering
  • push (sti, [tilstand]) : (funktion), skubber en ny post ind i historikstakken
  • erstatte (sti, [tilstand]) : (funktion), erstatter den aktuelle post på historikstakken
  • go (n) : (funktion), flytter markøren i historikstakken med n poster
  • goBack () : (funktion), svarende til go (-1)
  • goForward () : (funktion,) svarende til go (1)
  • blok (prompt) : (funktion), forhindrer navigation

Så lad os konsolere.log historieobjektet i vores hjemmevisning og se, hvad det viser:

Okay, præcis hvad vi forventede.

Det fortæller os, at vi er havnet her med en PUSH handling, at længden af objektet er 40 (som du navigerer gennem din app historie vokser til 50 og stopper der, kassere de ældre poster og holde sin størrelse hver gang app skubber en anden historieindgang i objektet).

Det giver os placeringsoplysningerne .

Igen, historie objekt er foranderlig . Derfor anbefales det at få adgang til placeringen fra de gengivne rekvisitter af Route , ikke fra history.location .

Dette sikrer, at dine antagelser om React er korrekte i livscykluskroge.

For eksempel:

Du kan typisk bruge den til at ændre browserens URL-sti.

I eksemplet nedenfor undgår vi og opret en knap, der skifter historik:

Selvfølgelig kan du bruge det til at udløse URL-ændringen efter nogle data hentning eller bivirkninger.

Det er behageligt at bruge det midt i JSX, hvor du ikke vil påberåbe komponenter. Du kan simpelthen returnere et historikskub og udløse Router for at opdatere browser-URL'en.

Sidst men ikke mindst

Jeg tror, ​​at du på dette tidspunkt allerede har en god idé om, hvordan du bruger match , placering og historie .

Jeg foretog ingen ændringer i vores oprindelige kedelplade, så føl dig fri til at lege med den i den samme repo, der er leveret i del 1 i denne vejledning.

05. Bibliografi

For at lave denne artikel har jeg brugt dokumentet React Router, som du kan finde her.

Alle de andre websteder, jeg har brugt, er knyttet sammen med dokumentet for at tilføje info eller give kontekst til det, jeg har forsøgt at forklare dig.

Denne artikel er del 2 af en serie kaldet “Hitchhiker's Guide to React Router v4”

  • Del I: Grok React Router på 20 minutter
  • Del III: rekursive stier, til uendelig og videre!
  • Del IV: rutekonfiguration, den skjulte værdi ved at definere et rutekonfigurationsarray

? Mange tak!