20. React-teamets julklapp: Server Components
lyssna!
I det första avsnittet inspelat 2021 ventilerar vi först lite om ångesten över semesterslut och långa startsträckor, men sen hoppar vi in på dagens huvudsakliga ämne: React Server Components. Ett nytt sätt att skriva Reactapplikationer där du kan välja vilka komponenter som körs i webbläsaren och vilka som renderar på servern. Anton har testat och är (som vanligt) rätt pepp!
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Varför var den funktionella programmeraren så bra på att läsa grafer?
Dålig Scala.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att
klicka precis här :)
Varför var den funktionella programmeraren så dålig på att läsa grafer?
Ehh... Gud, jag kommer inte ens på en funktionell språk som det här kan dras till.
Jag vet inte, varför?
Dålig skala.
Alltså, ja...
Och jag satt och tänkte, ja, Haskell. Det kan man inte få ett tillitskämt på.
Challenge accepted, nej.
Ja, varsågod. Till nästa avsnitt hoppas vi på.
Ja, det kommer inte att bli något.
Okej, välkomna till ett nytt avsnitt av ASDF.
Jag känner mig jävligt ringrostig.
Jag har fan inte poddat på två månader.
Nej, det är trögstartat nu känner jag.
Vi körde ju en batch med avsnitt innan jul för att kunna vara lite lediga inom situationssägen.
Och det funkar bra ändå.
Men nu är det ju exakt så här segstartat var jag efter jul med jobbet också.
Ja, jag har bara en känsla av att så här obekväm har jag nog inte känt mig på länge.
Lite så.
Ja, men det förstår jag. Jag hade det extremt tungt att komma tillbaka till jobbet.
Ja, jag hade nog snarare så här att jag hade otroligt mycket ångest över att komma tillbaka till jobbet.
Jag ville verkligen, verkligen inte. Men första dagen där så rivstartade det bara.
Och då har det bara rullat sen dess.
Ja, men det är ju nice. Jag tror min startsträcka var en vecka innan jag kände att nu börjar jag.
Nu är jag vant mig att jobba igen.
Och då hade jag bara varit ledig två veckor över jul.
Ja, du var ledig fyra veckor.
Ja, exakt. Du kanske kom över någon puckel där att när du väl kom tillbaka så hade du en energi.
Ja, för jag tror fjärde veckan så kände jag mig nog stress...
-3,5 dag, för att sista tiden gick jag åt till att stressa efter att jag var trungen att börja jobba igen.
-Ja, men du hade ändå en halv vecka.
-Ja, för jag kollade på mitt sömnmönster. Det var någon vecka då jag faktiskt sov mer än 8 timmar varje natt.
Och det har ju inte hänt sedan jag skaffade min jävla Apple Watch.
-Ja, men det är ju spännande ändå. Men det är ju fan kul att vara igång igen, tycker jag. Jag är ändå taggad.
- Ja, du är ju pepp. - Jag är ju pepp, som vanligt.
[Skratt]
En grej som hände över jul var ju att React-teamet gick ut med en bloggpost
där de pratade om React Server Components, eller introducerade det,
som är någon experimentell grej de pysslar med.
Och de sa "här är en julklapp från React-teamet".
Men jag tänkte att vi kunde snacka lite grann om det idag, kanske.
- Mm, det kan vi göra.
Jag såg den och jag likade den och läste den inte som rimligt millennial på sociala mediebeteende.
Exakt.
Så det får du gärna...
Du fick liksom ingen varning så här "Vill du verkligen lika den här?"
Även fast du inte har läst den.
Nej.
Det är väl bara retweets på Twitter som har den funktionen tror jag.
Ja, och de introducerade det i en bloggpost som var första grejen.
Sen finns det en video som är typ en timme lång där Dan Abramov och Lauren Tan går igenom vad det är för något, varför de har gjort det och en demo.
Sen finns det en demo som sagt, så det är open source.
Och sen finns det även en RFC, alltså vad det står för, Request for Comments.
Ja.
Tror jag, som är det. Det är liksom ett sätt att föreslå ändringar typ på saker.
Ja, det är väl ett sätt för dem att öppna upp och ge oss feedback. Vi vill ha feedback.
Ja, men exakt. Och den är lite mer teknisk.
Så jag har tagit mig och tragglat mig genom allt av det här.
Men det var två veckor sedan kanske, så jag är inte helt up to date på allt som händer.
Men om man ska sammanfatta det väldigt kort så är det ju egentligen ett sätt
För vissa komponenter att köra via servern eller rendera via servern.
Och samtidigt kunna ha vissa komponenter som bara renderar på klienten.
Det är egentligen vad det är för något.
Anledningen till att de gör det här, de pratar i den här videon som jag kan rekommendera.
Är man intresserad så rekommenderar jag verkligen att kolla på den.
Den är bra mycket om det här "good, fast, cheap".
Som brukar vara en triangel där man kan välja två.
Och enligt det här tycker de att det här är en lösning där du kan få alla tre.
Du kan få bra UX, du kan få bra snabb performance, och den kommer inte göra banden större.
För det är också den stora grejen att serverkomponenter påverkar din JavaScript-bandel 0%.
Det är liksom 0,0 KB.
Ja, men är det tänkt att det är komponenter som du renderar på servern,
sen när du börjar interagera med dem tar klient-renderingen över?
Nej. Det är här som är lite skillnaden jämfört med server-rendering.
Jag har inte ens kört skitmycket server-rendering i React.
Jag har kört ganska mycket.
För där är det ofta att du server-renderar bara "first load" egentligen.
Och sen så har du att du har den här "rehydrate" eller "hydrate" eller vad det nu kallas.
där man låter JavaScript ta över renderingen.
I det här fallet är det en av de stora skillnaderna att
här kan du fetcha om dina serverkomponenter hur många gånger du vill.
Så en serverkomponent renderas alltid på servern.
- Okej, men då kommer du ändå vilja välja sådana komponenter som inte är
är att du som användare i UX vill ha direkt återkoppling?
Ja och nej kanske. Det finns lite fasta begränsningar, eller hårda begränsningar.
Det är typ att serverkomponenter inte kan ha något state eller interaktivitet.
Alltså det vill säga att de inte kan innehålla just state eller just effekt.
Då blir det ingen interaktivitet från en användare?
Nej, exakt. Och de kan inte ha interaktioner med domen eller clickhandlers och sådana grejer.
Så det är en hård begränsning som finns.
Och sen tror jag den andra begränsningen är att den props de tar måste vara serialiserbara.
Alltså kunna serialiseras till JSON i stort sett.
Så att du kan till exempel inte skicka in en funktion, för den kan man inte serialisera.
Och sen finns det väl några fler undantagsfall som inte kan serialiseras.
Men det är typ de begränsningar som finns.
Sen då, gör ju det inte så mycket.
Jag kan ta ett exempel snart, som jag tycker illustrerar jävligt bra vad det är för något.
Men i vilket fall, det man gör egentligen är att man rent praktiskt
så döper komponenterna till komponentnamn.server.js
eller komponentnamn.client.js
Då indikerar du om det är en klientkomponent eller en serverkomponent.
Har de då server-suffixet så körs de på serverna och har de en client så körs de på klienten.
Lämnar du det där suffixet helt och hållet så att de inte har något av dem,
då säger man egentligen att den här kan köras på båda ställena.
Den kan dyka upp så att klienten renderar den om det är så,
men är det så att servern renderar den, då kommer den att renderas på servern.
Men då skulle det fortfarande innebära att den måste ha de restriktionerna?
Exakt, precis. Så att det blir fortfarande samma restriktioner men den liksom
säger att en klientkomponent renderar en komponent som inte är spesad
då kommer den förmodligen att renderas av servern.
Eller förlåt, av klienten såklart.
Och tvärtom, om serverkomponenten renderar en så kommer den att renderas av servern.
Om det liksom är ett barn till en serverkomponent.
Ja.
Jag kan serverkomponenterna ha klientbarn?
Och det här är också lite coolt för att det som händer när servern renderar de här
det är inte att den skriver ut det till domobjekt eller demmer eller någonting sånt
inte heller JSON utan det är något annat.
Exakt vad det är är något som är specifikt till React Server Components.
Så den datorn som skickas mellan servern och klienten är något som är
som är "Det här är bara för React Server Components, det här är den datan den behöver".
Varför det är gjort så vet jag inte. Jag tror att de går in lite på det i RFC och varför det funkar så och hur det ser ut.
Men det känns som att är man inte känd av det kan man läsa den så att säga.
Men mycket av det den möjliggör är bland annat att
till exempel då i ditt fall som du sa att du har en serverkomponent som har ett klientkomponent som barn.
Om serverkomponenten ska renderas om, säg att vi ändrar props på den till exempel.
Då kommer den requesta den från servern och servern svarar med det här datat.
Och då kommer fortfarande statet i klientkomponenten som den har som barn.
Det kommer fortfarande behållas.
Så det är en stor skillnad till exempel med serverrendering.
Där blåser man ut och staten försvinner, men här kan den behålla allting.
Och det är för att de har gjort massa smart i React som håller koll på om det här är barnkomponenter och om de är klientkomponenter med state eller inte.
- Ja just det, fan vad avancerat. - Det är, när jag började kolla på det här så kände jag, fan det här kommer bli komplext.
Och liksom så här, fan, och kände liksom att det blir ytterligare ett abstraktionslager på något sätt.
Det krävs någon typ av Node-server i bakgrunden också.
Jag tror att det är bara där det funkar med just nu.
Jag vet inte om det finns planer på att det ska funka med andra backends, men
det är liksom som det är uppsatt just nu.
Sen...
Det här demot är också väldigt coolt.
Det är bara en "to do"-app, eller "note-app". Du kan skriva anteckningar i.
I stort sett.
Och det är hela appen. Men den visar ganska bra på saker man kan göra.
Och det de har till exempel är en sök-komponent som är serverrenderad.
Eller en resultat-komponent kanske man ska säga.
Själva inputen är såklart klientrenderad för att den måste ha lite domhantering och "on-change-handlers" och sånt.
Men själva resultatlistan, den som visar resultatet och den som gör själva sökningen, den är serverenderad.
Och det enda de gör i det här exemplet är att de skickar in en prop som då är typ "search string".
Vilket då är det man söker på.
Och det som händer är att varje gång du ändrar den proppen då kommer den då gå till servern och hämta den här komponenten.
I serverkomponenten, och nu blir det lite mindfucket.
Det de gör i det här exemplet, och de rekommenderar att man inte ska göra så här, men det är bara för att bevisa att det går,
är att de använder i komponenten, så använder de Node, för att querja en databas direkt i komponenten med SQL.
Läsa upp resultatet baserat på den här proppen och sedan rendera ut det då.
Oj.
Ja.
Vänta, vem renderar? Är det den här serverkomponenten som renderar klientbarnet med inputfältet?
Eller klientbarnet med inputfältet skickar väl liksom sin...
Ja, men jag tror att inputfältet och listan är nog inte...
De är inte i samma hierarki så att säga.
Okej, men då får du ändå den här söksträngen från inputkomponenten.
Ja, precis.
Och passar den som prop.
Den passar till en prop till den här serverrenderade listan.
Som sedan då, med SQL.
Vi har en SQL-fråga.
Gå direkt till en databas via Node.
Få tillbaka resultatet.
Och då har vi den resultaten, så då skickar jag bara upp datan för hur det här skulle se ut.
Och sen kommer det att renderas.
Ja.
Och det är ju jävligt coolt.
För att helt plötsligt så behöver du inget API.
Nej.
I verkligheten vill man förmodligen inte göra ett SQL-anrop i koden, men du kan ju ha något annat.
Ett annat abstraktionslage som du läser vad du nu vill läsa.
Du kan till exempel läsa från disk.
Om du skulle vilja det.
Så det är mycket sådana här grejer som blir jävligt coolt plötsligt.
För att istället för att göra ett API-anrop, då ändrar du bara en prop.
Och så sker det automatiskt.
För att den kör på serverdelen.
Och då har ju den tillgång till sådana saker.
- Ja, det är lite sjukt alltså.
Och stökigt.
- Jag tror att det kan säkert bli jävligt stökigt.
Men där de pushas en mycket fördel med det här är ju att
det blir en hybridapp mellan server och klient.
Och att den skalan är ganska arbeträr eller sliding.
Du kan bestämma på en case by case basis
vad som ska vara på servern och vad som ska vara på klienten.
Istället för när man gör serverendering oftast gör att allt eller inget.
Ja, för jag kom väl in i webprogrammering, fan vad lite jag kunde webbföredra.
Men jag kom väl in efter hela POP-storhetstiden.
Men jag har väl sett att folk säger att det här är att gå tillbaka till POP.
Eller tankarna som fanns.
Det är mycket memes om POP is back.
Och det är väl för att det påminner lite grann om det.
Sen är det ju fortfarande att med PHP var det ju fortfarande att
det var ju kanske mer serverrendering där.
Det var ju liksom inte samma sak att du hade sin sådär,
du spesade en komponent om den skulle vara server eller klient.
För ska du köra den på klienten med PHP så behöver du ju jag och Skepticson.
Ja.
Så att jag skulle säga att det är väl, jag fattar folks memes.
Men det kanske inte är en helt rättvist liknelse.
Och sen då som sagt, som vi pratade om innan, att den behåller state. Till exempel då om, säg att varje item i den här listan med söksresultaten, de är ju interaktiva.
Så det är ju liksom en klientkomponent.
Okej, så att liksom serverkomponenten får resultaten och säger, rendera de här resultaten i komponenter då.
Exakt, och de har även lite state på om de är aktiva eller inte.
Om du klickar på den så dyker själva anteckningen upp till höger.
Så du har en sidebar till vänster i den här demot.
Det statet lever också kvar när du söker.
Så när du söker och säger att den du har valt fortfarande är kvar i listan
då kommer den fortfarande ha kvar sin markerad state.
Just det, för du inte wipar något state.
Exakt.
Däremot då ligger det väl på att då behöver du väl egentligen uppdatera ditt state
beroende på gamla och nya saker du får in i klientkomponenten?
Det blir inte så stor skillnad vad man behöver göra i vanliga fall.
För det som kommer hända är att den här listan uppdateras bara.
Och sen vilken som är aktiv, det spelar egentligen ingen roll.
Det blir fortfarande väldigt deklarativt.
Du klickar på en i listan, den öppnas som aktiv.
Du kanske söker och det som händer då är att listan uppdateras.
Finns det där itemet du klickade på kvar, då kommer den vara markerad.
finns det inte kvar, då är det inte markerat längre.
Om man inte söker igen och den går tillbaka, är den fortfarande markerad då?
Jag skulle tro det. Inte testat i det emot faktiskt, men det är en bra fråga.
Sådana där saker är väldigt spännande.
Det är ju sådana där saker som kan driva en till vansinne.
Ja, det är det ju definitivt.
Det var något jag tänkte säga.
Sen är det väl lite det här med att allt det här funkar med suspense.
Också out of the box.
Så om en serverkomponent tar lite länge på sig att svara och man har rappat den med suspense
så kan man använda det som fallback för loading states och transitions och grejer.
Ja och suspense är den här när man säger att man får en fallback på loading.
Så länge den fortfarande laddar så kan du visa någonting annat i gränssnittet innan det du faktiskt vill visa har laddat klart.
Exakt. Vi kan nästan prata i ett helt avsnitt om suspens också för det var en jävla lång resa för React på det mesta.
Med suspens och det som inte finns och det som finns i React nu och allt som är experimentellt.
Ja, för de backade väl lite med den där just för server-renderingen.
Liksom det där första caset, vi pratar inte det här då.
Utan att du renderar komponenter på både servern och klienten.
Det klarade väl inte suspense därifrån början.
Och då tror jag de väntade lite med att släppa allt.
Ja, men exakt. Så nu finns det vissa delar av suspense som de rekommenderar att använda.
Väldigt dålig på att använda suspens hittills faktiskt.
Jag vet inte om det blir tidspress eller man inte har tänkt på den.
Vi borde göra det mer i projekt.
Ja, men det känns som att det är en...
Jag tror att det är mycket kommen från kommunikationen
som React-teamet hade när de lanserade det.
Att det var så här "Titta vilken cool grej vi har gjort, använd den inte än."
Och sen bara "Fast den här grejen, den kan jag använda."
"Men inte det här."
"Ja, det här är typ klart, men förresten, det här kommer vi dra tillbaka."
"Vi måste tänka lite till på det."
Suspens kommer snart, tre år senare.
För ett tag när de pratade som S-hållare,
"Det här finns i alfan, men använd inte det i produktion."
Men inte i produktion. Så då vet jag att jag använder det i nån typ av hack-dej-grej.
Sen har jag nog glömt bort det, tror jag.
Ja, precis. Det är kraftfullt som fan, men man tänker aldrig på att använda det.
Det är så lätt att bara göra en if-loading.
-Gör det här istället. -Speciellt med hooks.
Ja, exakt. Jag är ganska taggad på det här. Det här är superexperimentellt också.
De är väldigt så här "använda inte det här i produktion, försök inte ens göra det, lär inte ut det i kurser eller någonting sånt,
utan det är absolut inte klart, det kommer säkert ändras jättemycket innan det är klart".
Uppenbarligen har den kommunikationen lärt sig av suspensfiaskot, kanske man får säga ändå.
Jag gick in på fel då, när jag skulle kolla igenom den här lite fort tänkte jag.
Så jag missade ju bloggposten utan jag gick in på videoposten.
Och där står det verkligen så här, vi har börjat kommunicera det här för transparens.
Och inte för att det egentligen är någonting som är klart.
Utan vi vill att ni ska se vad som händer.
Och sen med de andra som du säger, använd inte det här nu. Please.
Nej men exakt. Så det ska bli väldigt spännande att se fortsättningen, vart det landar.
Jag tror att det kommer hjälpa mest för olika frameworks som Next.
De kan använda det här på ett väldigt bra sätt.
Där har du att du kör en Node-server också redan nu.
Då kan man inkorporera det här på ett smidigare sätt än om man bara har kört en statisk app.
Ja, men det är intressant om man kollar den newscasen och vad det öppnar upp för.
Som till exempel nu så sitter jag ju i en klientrenderad applikation, där vi har jättemånga stora komponenter som gör GraphQL-frågor eller restfrågor för att hämta all data.
Som vi gör direkt i den komponenten som ska rendera och sen hela det trädet som lever på den datan.
Och då har man ju byggt en back-end såklart egentligen bara för att skapa ett API för läsmodeller.
Så vad gör man med den biten så då? Den skulle man ju kunna börja eliminera eller bygga ihop det på ett helt annat sätt.
Ja men exakt. Det är ju väldigt spännande. Jag tror att jag läste, om jag minns siffran rätt nu, så tror jag att de skrev i stora projekt så hade de sett en minskning på upp till 29% av javskräpbanden också.
Och det är en jävla bit.
Ja, verkligen.
Det är nästan en tredjedel av all JavaScript som kan försvinna för att man konverterar komponenter till serverkomponenter istället.
Sen tror jag att det kommer, som vi var inne på innan, att det kommer bli en komplexitet som gör det svårare att jobba med.
Att det blir en till sak att tänka på, att om det är en serverkomponent så måste du tänka på det här också.
Sen tänker jag mig att det kommer säkert typ ESLint-regler som säger bara att, ja, tänk på att om den är delad upp i .server.js då kommer den klaga på om du använder justate eller alla de här reglerna.
Ja, det får någon fixa.
Ja, jag tänker bara att någon får göra det. För det är liksom samma sak. Hur många gånger har man liksom inte råkat göra något konstigt med typ hooks och så klagar den där på, ja, du har lagt en hook efter en if, typ.
Och man bara, ja, just det.
Ja, du har missat det här i dependency-arrayen.
Den har man vant sig i nu. När man har suttit med Hooks i några år.
Så stoppar man in den i Dependency Array och sen looperar den i en helhet.
"Jag har byggt det här fel, men jag har inte tid, så jag lämnar ut den ur Dependency Array och lever med varningen."
"Islint Disable" eller React X Hosted Deps eller vad fan det heter.
Ja, det är lite ångestfyllt.
Ja, det skulle ju kunna påverka hur vi bygger webbsen.
Om det är tänkt att man ska bygga ihop allt i en enda, det får ju bara framtiden visa.
Men det är ju häftigt att det rör på sig på så här sätt.
Prova nya saker och flyger de inte så gör de inte.
Men det är, jag menar, SEO-bitarna och applikationer som är server- och klientrenderade,
Det skulle också kunna öppna ganska mycket nytt, häftigt antagligen.
Ja, definitivt. Det är en stor grej som folk har.
Vi måste serverendera det här på grund av det här.
Då är det ofta SEO som är den stora biten.
Men att man då skulle kunna bara serverendera de publika sidorna man har,
eller man slipper göra det på de interna.
Det är ett väldigt starkt use case.
Ja, om det inte börjar tolkas som att det är cloaking.
Google indexerar ju klientrenderad JavaScript nu för tiden.
Hur många andra sökmotorer optimerar vi för nu för tiden egentligen?
Nej, så är det verkligen.
Google styr våra liv.
En annan grej som jag kom på nu precis, men jag glömde nämna, är också att säga att en serverkomponent renderar en klientkomponent.
Då kommer den automatiskt codesplitta klientkomponenten.
Så den kommer inte laddas in, den banden kommer inte laddas in, förrän den serverkomponenten kommer från servern.
Oj vad jag zonade där, förlåt.
Ja, det är det. Som ett exempel då.
Om vi tar exemplet den här appen, eller demappen som den hade.
Då säger att vi har en, vi kan ta det exempel vi hade.
Vi hade listan som var serverrenderad.
Just det, säkerhetsresultaten.
Ja, exakt. Men sen varje item i listan, eller varje träff i listan, den är klientrenderad.
Då kommer liksom JavaScriptet för varje item,
Den kommer få en egen bundle som inte laddas in förrän listan har skickats från servern.
Så att den inkluderas inte i data som kommer från servern.
Men klienten vet om att "ah, här kommer en klientkomponent som inte har laddat än".
Och då laddar den in den bundlen så att den är automatiskt code-splittad.
- Ja just det, men den laddar ju inte in någonting för varje barn utan för bara den komponenten som alla barn har använt.
- Ja men precis.
Så det är också en sån här smart grej.
Nu vet man trädet i förväg hur det ser ut.
Då kan de räkna ut att den här komponenten kan vi lägga i den här banden för då kan den läsas in tillsammans med
när den här serverkomponenten värderas någon gång.
Sen var det kanske ett dåligt exempel för att den där listan visar sig förmodligen alltid i en appen.
Men att man går in i ett edit-läge till exempel och det är en serverkomponent.
Ja, men exakt.
Och att den har en klientkomponent som barn.
Så det gör jag också. Code splitting har jag suttit med så jävla många gånger.
Jag vill få till det lite bättre än vad det är, eller jag vill få till det överhuvudtaget.
Och jag vet inte, det går ju som aldrig enkelt.
Och så finns det en miljard olika sätt att göra det på.
- Och så drar man upp den här jävla bundle-analyzern och tittar på de stora, de här g-sippade, och vilka som har vilka.
Det där är lite som när jag sitter och tittar på performance-tabben.
Jag blir ju återigen, det är för mycket. Jag kan inte, det backar bara.
Nej Alma, det är inte en så rolig grej att hålla på med.
Så om det bara funkar automatiskt, gärna för mig.
Ja, jag kommer inte sörja.
Så liksom att jag inte får göra det här.
Sörja manuell code-splitting.
Får ta en gravöl för det.
Nej, fan.
Ja, men det var nog det jag hade om RSCs React Server Components.
Jag tror att den där förkortningen blir mer och mer populär.
Jag har sett den på många ställen nu när jag läser om det.
Fortfarande måste jag stanna upp varje gång och bara "RSC? Vad fan är det?"
Ja, jag klarar egentligen inga akronymer. Min hjärna bryter ihop lite.
Men det är lite av ett första i den här podden att någon hade med sig anteckningar.
Ja, men jag hade ändå en tiorad av anteckningar.
Det är stort känner jag.
Ja, det är ändå välpreppat.
Ja, mer strukturerade än någonsin.
Exakt.
Med det sagt så tackar vi väl för oss den här gången och så hörs vi om två veckor.
Ja.
Bye bye.
Tja.
[Musik]
Hej då!
