Lad os forelske os i React Fiber

TLDR, React Fiber er en intern motorændring, der gør det muligt for React at bryde grænserne for opkaldsstakken. Oprettelsen gør det muligt for React at standse / starte gengivelse efter eget valg. Til sidst vil React-brugere være i stand til at antyde "arbejdets" prioritet.

I øjeblikket kan vi ikke direkte interface med det, så hvorfor skal vi være interesserede i det? Fordi det er virkelig freaking cool!

Reager før Fiber var som at arbejde i et tempofyldt firma uden git.

Forestil dig at være midt i en enorm funktion, og din chef har brug for et hotfix, pronto. Du kan dog ikke stoppe med at arbejde, fordi alle dine ændringer er i en fil, er du forpligtet til at afslutte dette arbejde.

Hvis vi brugte git, ville vi være i stand til at forpligte vores arbejde til en filial og skifte til en hurtig hotfix-gren.

Med Fiber kan React pause og genoptage arbejdet efter ønske for at komme i gang med det der betyder noget hurtigst muligt! ?

Reager Internals i en nøddeskal?

Du opretter et komponentetræ. React tager dette træ, går igennem det og skaber en virtuel model af slutresultatet. Måske gengiver du til DOM, måske målretter du mod indfødte. På dette tidspunkt betyder det ikke noget at reagere.

Nu, når din app opdateres, vil React udføre processen med at skabe det virtuelle resultat igen og igen. Hver gang sammenligner det det forrige virtuelle træ med det næste.

På dette tidspunkt bliver vi platformafhængige. Hvis du gengiver til DOM, kan det være, at kun en klasse på et element ændrede sig. React vil gå gennem det virtuelle træ, finde hvad der er ændret og opdatere så lidt som muligt.

Dette kan betyde at opdatere en klasseattribut, eller det kan betyde at nedbryde hele DOM. Dette er forsoning.

Før Fiber var dette det. Arbejdet blev lagt ud, og den valgte renderer kom på arbejde. Selvom browseren forsinkede, brugeren skrev, eller planeten var ved at eksplodere, ville render-toget ikke stoppe. ?

Hvordan fungerer det (på et højt niveau)?

Med Fiber er der nu forskellige prioritetsniveauer for opdateringer. Opdatering af et input, som en bruger skriver, har højere prioritet end en liste med tusindvis af komponenter.

Fiber bryder træberegning i enheder af arbejde, som den kan "begå" til enhver tid. Så hvad er en enhed af arbejde? Det er simpelthen en knude i dit komponenttræ!

  1. React kan nu pause, genoptage og genstarte arbejdet på en komponent. Dette betyder, at visse livscykluskroge kan skyde mere end en gang.
  2. React kan have et prioritetsbaseret opdateringssystem. Dette giver React Teamet mulighed for at finjustere rendereren, så React er hurtigst i de mest almindelige brugssager.

Jeg vil dog fokusere på det første punkt lidt. React bevæger sig væk fra (men støtter stadig!) Nogle gamle livscykluskroge og tilføjer nogle nye! ?

componentWillMount, componentWillUpdate, componentWillReceiveProps, Kan nu skyde flere gange. Du bør ikke udløse bivirkninger her.

Nu vil du affyre bivirkninger i livscykluskrogene, der kun affyrer en gang: componentDidMountogcomponentDidUpdate

For at kompensere for mange brugssager, der componentWillReceiveProps dækkede, modtager vi to nye kroge.

  1. getDerivedStateFromProps som ikke har adgang til tidligere rekvisitter eller komponentforekomsten, men giver dig mulighed for at synkronisere tilstand med dine rekvisitter.
  2. getSnapshotBeforeUpdategiver dig adgang til DOM, før den opdateres. Den værdi, du returnerer, kan bruges i componentDidUpdate.
Fra og med React 16.4 udløses nu getDerivedStateFromProps altid før renderingsmetoden. Ikke kun når rekvisitter opdateres!

Sammenfattende giver Fiber React mulighed for at finjustere gengivelse for at sikre, at de vigtigste opdateringer sker så hurtigt som muligt, alt sammen for de lette omkostninger ved nogle livscyklusknager og gallon Facebook-blod. ?

Hvis du har spørgsmål eller er på udkig efter en-til-en-reager mentorskab, er du velkommen til at tweet mig @yurkaninryan når som helst!

Hvis du kan lide min skrivestil, er der nogle andre artikler, jeg har lavet.

Held og lykke og glad kodning! ??