Sådan bruges React.lazy og Suspense til komponenter med doven belastning

React 16.6 bragte kodedeling til et nyt niveau. Du kan nu indlæse dine komponenter, når det virkelig er nødvendigt uden at installere yderligere biblioteker.

Hvad er kodedeling og doven indlæsning?

Webpack definerer kodedeling som:

“Teknik til opdeling af din kode i forskellige bundter, som derefter kan indlæses efter behov eller parallelt”. [Kilde]

En anden måde at sige på: "loading on demand eller parallelt" er lazy-loading .

Overfor lazy-loading er ivrig-loading . Her er alt indlæst, uanset om du bruger det eller ej.

Hvorfor bruger vi kodedeling og doven indlæsning?

Nogle gange er vi nødt til at introducere et stort stykke kode for at dække nogle funktioner. Denne kode kan importere tredjepartsafhængighed eller skrive den alene. Denne kode påvirker derefter hovedbundtets størrelse.

Download af et par MB'er er et stykke kage til dagens internethastighed. Vi er stadig nødt til at tænke på brugerne med en langsom internetforbindelse eller ved hjælp af mobildata.

Hvordan blev det gjort før React 16.6?

Sandsynligvis er det mest populære bibliotek til doven indlæsning af React-komponenter react-loadable.

Det er vigtigt, at reactjs.org stadig anbefaler, react-loadableom din app gengives på serveren. [Kilde]

react-loadableligner faktisk den nye tilgang fra React. Jeg vil vise dette i den følgende demo.

Er der behov for noget til opsætningen?

Lad os se, hvad reactjs.org har at sige om det:

"Hvis du bruger Create React App, Next.js, Gatsby eller et lignende værktøj, har du en Webpack-opsætning ude af kassen til at samle din app. Hvis du ikke er det, skal du konfigurere dig selv sammen . Se f.eks. Vejledningen Installation og Kom godt i gang på Webpack-dokumenterne. “

- reactjs.org

Ok, så Webpack er påkrævet, som håndterer dynamisk import af bundterne.

Den følgende demo genereres ved hjælp af Create React App.Og i så fald er Webpack allerede konfigureret, og vi er klar til at gå.

DEMO

Til denne demo bruger vi react-pdf. react-pdfer et fantastisk bibliotek, der bruges til at oprette PDF-filer på browseren, mobilen og serveren. Vi kunne generere en PDF på serveren, men hvis vi hellere vil gøre det på klientsiden, kommer der en pris: bundle-størrelse.

Jeg bruger importomkostningsudvidelse til Visual Studio-kode for at se størrelserne på de anvendte biblioteker.

Lad os sige, at vores krav er at generere en PDF-fil, når en bruger klikker på knappen.

Nu er dette en simpel form med kun en brugssag. Prøv at forestille dig en enorm webapp, hvor dette er en brøkdel af mulighederne. Måske bruges denne funktion ikke meget ofte af brugerne.

Lad os sætte os i den situation. PDF-generation bruges ikke meget ofte, og det giver ikke mening at indlæse hele koden for hver sideanmodning.

Jeg prøver at vise, hvordan vi kan udvikle en løsning med doven belastning og uden den.

Ivrig VS doven læsning udstillingsvindue

I begge tilfælde bruger vi en komponent, der importerer afhængigheder fra react-pdfog gengiver et simpelt PDF-dokument.

Intet spektakulært foregår her. Vi importerer PDFViewer, Document, Page, Text, Viewfra react-pdf. Disse er alle anvendes i renderfremgangsmåde til PDFPreviewkomponent.

PDFPreviewmodtager kun en propkaldet title. Som navnet antyder, bruges det som en titel i en nyligt genereret PDF-fil.

pdfStyles.js ser sådan ud:

Ivrig indlæsning

Lad os først se, hvordan moderkomponenten uden doven belastning kunne se ud:

som gengiver følgende visning i browseren:

Lad os gennemgå koden sammen:

På linje 2 importerer vi PDFPreviewkomponent.

På linje 6 initialiserer vi tilstanden med standardværdier. nameer et felt, der bruges som en titel i PDF-filen, mens feltet PDFPreviewer en boolsk, der viser eller skjuler PDFPreview.

Lad os nu gå til rendermetoden og kontrollere, hvad der bliver gengivet.

På linje 19 og 25 gengiver vi et input og en knap. Når brugeren indtaster input, nameændres tilstanden.

Derefter, når en bruger klikker på "Generer PDF", showPDFPreviewer indstillet til true. Komponenten gengives igen og viser PDFPreviewkomponenten.

Selvom vi PDFPreviewkun bruger brugerklik, er al kode relateret til det inkluderet i app-pakken:

Dette er et udviklingsmiljø. I produktionen ville størrelserne være betydeligt mindre. Alligevel deler vi ikke koden optimalt.

Lazy loading

Vi har kun foretaget små ændringer, og lad os gennemgå dem.

Linje 2 erstattes med:

const LazyPDFDocument = React.lazy(() => import("./PDFPreview"));

Lad os se, hvad React-dokumenterne siger om React.lazy:

React.lazy tager en funktion, der skal kalde en dynamik import(). Dette skal returnere en, Promiseder løser, til et modul med en defaulteksport, der indeholder en React-komponent.

- reactjs.org

På linje 27 bruger vi Suspense, som skal være en forælder til en komponent med doven. Hvornår showPDFPreviewer indstillet til sand, LazyPDFDocumentbegynder at indlæse.

Indtil underordnet komponent er løst, Suspenseviser hvad der er leveret til fallbackprop.

Slutresultatet ser sådan ud:

Vi kan se 0.chunk.js- vægte betydeligt mindre end før, og 4.chunk.js og 3.chunk.js indlæses ved tryk på knappen.

Konklusion

Hver gang vi introducerer en ny afhængighed i vores projekt, er vores ansvar at evaluere omkostningerne og kontrollere, hvordan det påvirker hovedpakken.

Så skal vi spørge, om denne funktionalitet sjældent vil blive brugt, og kan vi indlæse den efter behov uden at ofre brugeroplevelsen.

Hvis svaret er ja, så React.Lazyog Suspensevirkelig hjælpe os med den opgave.

Tak fordi du læste! Del det med alle, der måske finder det nyttigt, og skriv feedback.