Interceptors i Next.js: – Høres likt ut mellomvare, men det er det ikke

Vannfall er bedre på serveren, og interceptors kan bli den nye greia i Next.js – her er ukas ForrigeUke.

Joachim Maksim forteller deg om hva i alle dager interceptors er for noe rart i Next.js. 📸: Bekk / kode24
Joachim Maksim forteller deg om hva i alle dager interceptors er for noe rart i Next.js. 📸: Bekk / kode24 Vis mer

Dette var uken for å høre på versjonskontrollert musikk 🎵, sjekke om tall er delelige på to 🧮, løse oppgaver asynkronoløst 📖 — og 583 andre ting som skjedde i frontend-verdenen.

Vannfall er bedre på serveren 💦

Ordet “vannfall” kan bli brukt i forbindelse med datainnhenting i Single-Page-applikasjoner, der flere forespørsler kjøres sekvensielt og er avhengige av hverandre.

Se for deg to React-komponenter, A og B. A gjør et kall, og venter på resultatet før B begynner å bli lastet inn. Da får du følgende sekvens:

A sender forespørsel ---> A får resultat
                          B sender forespørsel ---> B får resultat

Kent C. Dodds forklarer at samme oppførsel kan oppstå i server-komponenter, men at det kan være bedre å ha vannfall på serveren enn å ha det på klientsiden.

  • Som utvikler kan du nemlig sørge for at serveren din har en solid nettverkstilkobling og høy ytelse, men du kan aldri garantere dette på klientsiden.
  • I tillegg kan caching av nettverkskall gjøres på serveren slik at samme cache blir brukt på tvers av klienter. Dermed vil til og med førstegangsbesøkende kunne bruke cachede verdier, og unngå den uønskede vannfallseffekten.

Hvis noe av dette høres interessant ut, anbefaler jeg at du sjekker ut hele artikkelen.

Interceptors til Next.js? 🔜

Hendrik Liebau har publisert et utkast til en PR som legger til ny funksjonalitet i Next.js, med mål om å adressere noen av begrensningene til mellomvare:

✨Interceptors✨

Interceptors er funksjoner som kjører på serveren før en side rendres. De er godt egnet til å håndtere oppgaver som autentisering eller omdirigeringer.

Dette høres kanskje ganske likt ut som mellomvare, men det er noen viktige forskjeller.

En kul egenskap er nemlig at interceptors lar layouts bli rendret mens interceptor-koden kjører. Dette kan forbedre “First Contentful Paint”-metrikken, som måler tiden fra siden begynner å laste, til første element blir synlig.

En ulempe kan derimot være at brukergrensesnittet kan “blinke” hvis interceptoren omdirigerer brukeren til en side som ikke deler samme layout. Derfor anbefaler PR-forfatteren Hendrik Liebau at man kombinerer mellomvare og interceptors.

Han bruker autentisering som eksempel:

  • Når brukere besøker en side, bør de få se siden hvis de er innlogget, eller bli omdirigert til en innloggingsside. En brukers innlogget-status må altså sjekkes før sideinnholdet vises.
  • Det optimale i dette tilfellet vil være å ha en “rask og svak” sjekk av brukerens innlogget-status i mellomvare, og en tregere autentiseringslogikk i interceptoren.
  • Mellomvaren kan for eksempel sjekke om brukeren har en informasjonskapsel med riktig navn (f.eks. “auth-session”). Alle brukere som mangler denne vil umiddelbart bli sendt til innloggingssiden, uten å få det uattraktive “blinkende” brukergrensesnittet. For brukere med riktig informasjonskapsel, kan interceptoren gjøre ordentlig autentiseringslogikk, som ofte inkluderer trege databasekall, mens layouten allerede vises for brukeren.

I motsetning til mellomvare som må defineres i en middleware.ts fil i rot, kan interceptors bli definert hvor som helst i filstrukturen under /app. En side blir bare rendret etter at alle interceptors definert på samme nivå i filstrukturen, samt alle interceptors definert på nivåene over blir kjørt uten feil eller omdirigeringer.

Sjekk ut hele diskusjonen på Github om du vil lese mer om interceptors.