42. React 18
lyssna!
Therése är förkyld, Anton har fyllt 30 och med det i ryggen snackar vi om nyheter i React 18 som nyligen gått in i sin betaperiod. Allt från att den här releasen är mer spännande än den tråkiga React 17-releasen, concurrent mode vs concurrent features, automatisk batching, lite nya hooks och mycket annat kul.
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 känns det så tråkigt att spara persondata som JSON?
Jag gillar inte att objektifiera människor.
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 känns det så tråkigt att spara persondata som Jason?
Jag vet inte.
Jag gillar inte att objektifiera människor.
Det var kul. Det gillar jag. Bra. Jag skrattar.
Nu är vi igång. Nytt avsnitt av ASD. Det känns som om det var jättelänge sen jag spelade in.
Men det var det nog inte. Det var nog två veckor sedan.
Ja, det känns som en evighet i förkylningsår för min del sedan.
Ja, exakt. Du är förkyld. Jag har hunnit kliva in i 30-talet, eller 30-årsåldern i alla fall.
Välkommen.
Tack, tack. Det känns väldigt bra. Känner mig gammal?
Ja, det där får man inte alltid säga. För då säger någon "Du som är så ung!" och så blir man så här ageist.
Det är tråkigt.
Ja, men jag sa ju bara att jag känner mig gammal.
Jag vet, men det är för att jag alltid säger att jag känner mig gammal, men min kropp är typ 80.
[Skratt]
Jag är allowed.
Det lovar ju inte gott för framtiden.
Men, vad tänkte vi prata om idag?
Jo, vi tänkte prata lite grann om React 18, tror jag.
Kanske prata om lite grejer som kommer efter React 18 också.
Men vi kan väl börja där i alla fall.
För det släpptes ju beta för kanske tre veckor sedan, tror jag.
Om jag inte minns helt fel.
Vilket då skulle betyda att det är ungefär ett par månader bort så det släpps efter kanske januari, februari om jag får kill i sig lite grann.
Det ska väl komma ut någon release candidate och grejer innan det är klart.
Men efter det, om det inte dyker upp något väldigt mycket fel så kommer React 18 komma.
Och det känns ändå, jag är taggad. Det känns kul.
Ja, det gör det ju. För att 17 var ju hela den här, det har hänt massor under ytan för att förbereda för nästa major men det har inte hänt så mycket för användaren.
Exakt, för den var ju svidtråkig egentligen. Det var exakt som du säger, man sa "vi preppar så att man kan uppdatera till 18" eller "preppa till 17" så ligger man på 17 så ska det vara en lätt väg att gå till 18.
Men det är kul för jag tänkte inte alls att det var någonting som skulle påverka mig.
Men sen upptäckte jag att jag hade massa problem med att jag inte fick med mig eventvärdet in i mina setstate callbacks.
Men det läste de.
- Ah, i 2018 pratar vi om?
- Nej, i 2017.
Så i 2016 hade jag problem med det och sen kom jag på att de skulle fixa det i 2017.
Så det var faktiskt en liten ändring. Plus att man inte behöver importera React.
Ja, den var i och för sig trevlig. Även om min VS Code fortfarande inte har lärt sig det där.
Jag vet inte varför. Men den typ ger mig inte autocomplete på komponenter om jag inte har import React högst upp.
Först så föreslår den alltid "Vill du importera React?" och så måste jag klicka ja på den.
Och sen får jag förslag på "Den här komponenten är inte använd, vill du importera den också?"
Den ligger precis i filen här bredvid.
Det kan vara något som är fel-configurat i min VS Code.
- Jag har inte stött på det där. Min verkar snällare.
Eller så har jag bara inte byggt något.
[Skratt]
- Vi får väl säga att jag borde ta tag i att kolla det där.
Men det har aldrig blivit av. Det är inte ett så stort problem.
När den märker att det är en unjuiced import så tar den ju bort den också.
Den håller på lite där fram och tillbaka.
Lägg till React, ta bort React, lägg till React och så vidare.
Så den får extra jobba?
Exakt.
Men React 18 då
kommer med lite mer grejer tycker jag.
Det är lite saker som är ganska kul.
Lite saker som är så här, ja, det låter väl nice.
Men kanske inte tänkt på så mycket innan.
Men har du nåt så här som du är, fan det där låter skit nice.
Så här helt fruktansvärt för att jag läste igenom saker igår och det är så blankt i huvudet just nu så att du förstår inte. Jag kan inte frammana någonting.
Vi kan skylla på en förkylnings hjärna kanske.
Ja och fortfarande lite utbränt så att jag kommer leva på den vågen.
Det är ändå en våg du kan leva på. Så lite, det är kombinationen helt enkelt nu.
Jag har inte det men jag tänker att du har det.
Jo men jag har några grejer.
Det finns ju två saker som jag tycker verkar jävligt...
Den stora grejen som jag tycker är nice är att de har gått bort från det här med att
Concurrent mode inte finns riktigt längre.
Alltså att de har bytt från att det är ett mode till att det är Concurrent features typ.
För förut var ju Concurrent Mode, när det presenterades, jag vet inte hur länge sen det var, tre år sedan kanske
Har ju alltid varit att det är ett läge du sätter din app i
Så att du kan antingen köra typ Blocking som ska vara där man kör idag
Eller så ska det vara något mittemellanläge, eller så är det Concurrent Mode
Och att när du upptäcker 18 så får du tvungen att välja vilket läge du vill köra din app i
Och hela appen måste stödja det, vilket då inkluderar typ 3D-parts-libs och allting sånt
Men då har de gått bort från det nu till 2018 och sagt att vi har "concurrent features" istället.
Så när du använder en "concurrent feature" då optar du in den biten av trädet som du använder den på.
Vilket gör att man kan välja var man vill använda den och om man märker att det inte funkar på ett ställe så kan man skita i att använda det just där.
Just det. Jag kom på nu också vad jag tycker är nice.
Att de batchar fler state updates.
Ja, exakt. Det är ju faktiskt kul.
Jag tycker det är trevligt att de gör det, men jag har inte stött på det supermånga gånger.
Att jag har märkt varför min komponent renderar två gånger.
Mycket för att jag kanske inte bryr mig om hur många gånger min komponent renderar.
Men det är ju trevligt.
Jag kan ju störa mig väldigt mycket på extra renderingar.
Sedan är det också att jag har jobbat en del med performance.
Jag har inte alltid varit jättebra på det här med performance.
Så när man får lite bättre performance, bara out of the box, det tycker jag är väldigt skönt.
Problem blir lösta åt den.
Ja, det är väl därför man använder ramverk.
Det kan jag väl påstå.
Det är skitnice.
Och den skillnaden mot tidigare, nu tror jag om jag minns rätt, är väl att
tidigare har ju event handlers, om du har en onclick och skickar in en funktion i den
och så kör man två set states, så batchade vi den tidigare så att det blev en omrendering bara.
Men istället då om det var typ att du gjorde ett API-anrop och sen hade du ett promise som resolvade och i den resolven för det promise satte två states då fick du två renderingar för då visste React inte hur den skulle batcha det typ.
Nu ska den klara av att batcha alla sådana grejer tillsammans.
Exakt, så nu ska det inte spela någon roll om React inte vet vad som händer.
Om det är en clickhandler eller något utanför så ska den batcha.
Sen finns det en funktion, eller en hooker för att man ska kunna wrappa den om man vill ha specifikt en stateuppdatering.
Så det går alltid att komma runt den.
Ja, jag tror kanske att det är en funktion rakt upp och ner på React DOM, om jag inte minns fel, som heter typ "Flush" eller något i den stilen.
Ja, just det, för jag kommer ihåg också att det stod "Observera" att det är från React DOM och inte från React.
Ja, för tidigare fanns ju ett sätt att jobba runt det här problemet, som var typ "Unstable_batchedupdates" eller något sånt som också kom från React DOM om jag minns rätt.
Där man kunde liksom satt i din resolver för ditt promise i vårt exempel så kunde du liksom wrappa dina set states i den istället.
Och då batchade Reacten för att du satte den och gör det.
Men den är ju borta nu istället. Så nu blir det åt andra hållet att den batchar by default och sen får du opta ut från batchningen om du har någon anledning att göra det.
Jag vet inte till vart man skulle vilja göra det, men ja.
Jo men här sitter jag nu och så tycker jag att det är trevligt men jag bara, alltså om jag ändå ska sia om mig själv i framtiden så kommer det dyka upp ett tillfälle där man sitter såhär
Men varför sätter den båda staten samtidigt? Jag vill ju att den här ska sättas och sen ska den här sättas. Vad är det här om? Varför gör de såhär?
Och så måste jag komma ihåg, vilket jag inte kommer göra och hitta den här flashfunktionen och använda den. Jag kommer ju vara upprörd på det.
För att jag kommer ju inte ihåg saker, visligen.
- Uppenbarligen.
Men jag ser fram emot det.
- Det ska bli spännande. Vi kanske återkommer till en liten callback till avsnittet någon gång i framtiden.
När du berättar att du skriker över att React batchar saker.
- Ja, jag hoppas det.
Jo, och sen den andra grejen som jag tänkte på, det är väl två grejer egentligen, men är ju då två nya hooks.
Den ena heter Use Transition och den andra heter Use Deferred Value.
Just det, och båda sätter igång Concurrent Mode.
Ja, precis, båda är Concurrent Features.
Och det är jävligt svårt än så länge att förstå riktigt när man ska använda den ena och när man ska använda den andra.
Och ett litet sidospår här innan jag går in på de här huxen är att en annan grej som de har gjort nu inför React 18
i React Core-teamet är att de har bjudit in ganska mycket till diskussion kring de här featuresen
medan det har varit tidig alfa och så fort det kom där. Sen i somras någon gång tror jag
och haft ett repo på GitHub som heter React Working Group där de har bjudit in alla som har bidragit till React
har kunnat kommentera till det. Och så har de kört discussions-fliken på GitHub.
Och där har folk kunnat ställa frågor om saker och hur det funkar och fått förklaringar från core-teamet
eller andra som kan det. Och det tycker jag har varit sjukt nice. Särskilt för mig som är väldigt intresserad
av vart jag är på väg och vad som kommer att hända och hur folk tänker kring det.
Att bara kunna gå in där och titta lite grann. Och det finns vissa poster som är skitbra.
Det finns en som heter...
Jag ska se, jag tror till och med att jag har den öppen på en flik.
Den heter så mycket som "Glossary + Explain Like I'm 5".
Och då är det någon som heter Sylvia Vargas som har skrivit och gjort en tråd på det här React Working Group.
Varje inlägg under den här tråden är att hon ber folk förklara som att hon är fem år gammal olika termer.
Och vad det är för något. Så typ "concurrency" har en egen.
Där de försöker förklara vad concurrency är på ett så enkelt sätt som möjligt.
Och sen finns det typ, om jag skojar här så har vi "batching" och "automatic batching".
Vi har "hydration", "SSR".
Det finns mer "passive effects".
"Discrete events", "promise tick", "flush sync".
Vad var det du undrade om jag pratade om nyss?
Typ "code splitting", "debouncing".
Alltså det är skitmycket grejer som förklaras på extremt bra och pedagogiska sätt i kommentarerna bara.
Och mycket är Dan Abramov som går in och svarar, medan vissa andra går in på andra saker som de kan bättre.
Men vi länkar såklart den i beskrivningen också. Men jag kan verkligen rekommendera att gå in på den och kolla på den om man är lite nyfiken.
Och särskilt typ såhär "Vad fan är concurrency för något?"
Så finns det liksom en väldigt pedagogisk förklaring där.
[Therése] Jag blev bara såhär... Jag förstår ju begreppet. Och alla förstår vad det innebär.
Men jag är såhär "Vilken jävla brainig femåring alltså!"
- Ja, det ska erkännas. Jag kanske inte hade fattat det som en riktig femåring.
- Nej, men sånt där gillar jag verkligen. Det är så mycket antaganden om att alla fattar vad det här är.
Nej, för det är inte alltid lätt att komma in i det tekniska vokableret samt när det inte ens är native language, eller modersmål heter det på svenska.
Svenska och sådana saker. Så där är det alltid jätteuppskattat tycker jag.
Jag uppskattar det.
Ja, men verkligen. Samma här.
Och kan också nämna att, jag tror kanske vi nämnt det i en tidigare avsnitt, men de håller
också på skriver om hela React-dokumentationen från grunden upp.
Och man kan väl nästan räkna med att den förmodligen kommer liksom
sammanstråla lite grann med React 18 och innehålla saker om concurrency till exempel.
Där är det också mycket mer fokus på hur man ska tänka i React.
Till exempel finns det jättemycket om i ny dokumentationen.
Den ligger också uppe på beta.react.org.
Reactjs.org. Kommer aldrig ha vilken sida där.
Men den ligger också uppe där, så man kan gå in och titta och läsa den.
Den är inte helt färdig än, men också extremt mycket.
Och att den är "hooks first".
Så att de pratar inte om klasskomponenter längre.
Vilket de fortfarande gör i den nuvarande dokumentationen, vilket är ändå lite sjukt.
Gud vad jag inte visste det när jag pekade på den personen.
Fel av mig.
Men ja, Concurrency, jag tycker det är svårt.
Men jag tänker att du har lite bättre koll, så prata om de nya hookarna.
Jag kan väl nämna något om concurrency först också.
Jag tror att det är lite svårt att bara förklara "top of mind".
Men det handlar egentligen om att det är som concurrency.
Om man vet vad ordet betyder så handlar det om att man kan köra flera saker samtidigt.
Eller att saker kan överlappa.
Det det handlar om i React är att React blir smartare så att det kan hantera att om det kommer flera set states så kan de få lite olika prioritet.
I stort sett.
Och de här hooksen väger vi in lite i det här.
Men den kan avbryta rendering.
Alltså att den håller på att rendera något och så kommer det något som ska renderas igen.
Då kan den bara "ja men då avbryter jag den och sen så fortsätter jag att rendera"
"och sen om jag behöver börja omrendera så kan jag göra det."
Väldigt förenklad förklaring.
Jag skulle verkligen rekommendera att man går in och läser några artiklar eller den här förklaringen som vi pratade om nyss.
För att förstå vad det är.
Men i React 18 så kommer de här hooksen som vi pratade om.
Den ena heter Use Transition och den andra heter Use Deferred Value.
Och det är inte helt solklart hur de skiljer sig.
Det är ganska solklart rent tekniskt hur de funkar.
Men det är inte helt solklart vart man ska använda vilken.
För syftet är i stort sett samma sak.
Och de har liksom demat väldigt mycket i Start Transition eller Use Transition-hucken.
Det den gör är att du får tillbaka en funktion som kan kallas för start transition.
Och en boolean som är typ "is pending".
Vilket betyder då om den här transitionen är pågående.
Det man kan göra sen är att du kan wrappa dina set states i start transition.
För att säga till React att den här state-uppdateringen är inte akut.
Utan med den här statenplateringen så kan det bli så här "ja, vi sätter den när det hinner"
Och det gör ju att React kan anpassa sig. Så är det på en långsam dator så kommer kanske inte den där staten sättas på ett tag.
Men är det på en snabb dator så kanske det sätts direkt.
Och exemplet de har använt för att visa det här är typ någon open source app som de har använt.
Den renderar en typ av bubbelgraf med massa medicinsk information, typ om DNA tror jag det är.
Och sen finns det en slider man kan dra i för att filtrera den här.
By default då när du kör som React 17 idag, och drar i den här så sker det en set state på varje on change på den här sliden.
Och när den sätter statet så hänger sig i GUI-t.
Så både slidern hänger sig, det hoppar till i den här bubbelgrafen.
Och man märker verkligen att det känns som att datorn jobbar hårt när man drar i den så att säga.
Men sen så visar den då i det här demot att man kan wrappa den här set-staten bara med start transition.
Och helt plötsligt så är Slider-uppdateringen helt smooth.
Så att du kan dra i Slidern fram och tillbaka hur mycket du vill och den hänger sig aldrig.
Det som händer är att när React hinner köra en rendering av det värdet som du står på, då kommer den rendera om den här bubbelgrafen.
Men om inte annat så att Slidern kommer fortfarande vara smooth oavsett hur mycket det laggar i den här bubbelgrafen för att det tar tid att rendera den.
Och det är jäkligt coolt faktiskt. Det är så extremt lite förändring som sker men det får ett extremt hög påverkan för användarupplevelsen.
Det är ett extremt bra use case också.
För just den här med att man bara drar in slider ibland.
Lite okinnigensdrar i en slider för att se vad som händer.
Den är smooth fortfarande men att den per automatik väntar tills användaren har lugnat ner sig innan den ens uppdaterar allting.
Det är snyggt alltså.
Man ska också skilja på det här att det inte är en debounce till exempel.
För där är det typ att då spelar det ingen roll hur snabb dator du har, utan säg att man har sett en debounce på 250 millisekunder
Då kommer du alltid behöva vänta då minst 250 millisekunder från att du slutat dra slidern till att det uppdateras
Men i det här fallet så kommer den då anpassa sig så att kör du på en extremt långsam data, man kan ju liksom simulera det här i browsern
Då kommer det ta lite längre tid för att du släpper den, men är du på en snabb dator då kommer den liksom uppdatera
Eftersom med att du drar sliden behöver du inte släppa sliden för att den ska uppdateras utan den uppdateras för att den hinner göra det utan att GUI hänger sig.
- Ja, det här är ändå så stort. För det är liksom när man pratar så mycket om, vad ska man säga, ekonomisk skillnad i världen.
I världen, även när man pratar om IT och ojämlikheten, det handlar ju alltid om prestandan.
För att det är det som är den stora skillnaden.
Så att ta steg där vi i möjliga mån jämnar ut det här, det känns stort.
Verkligen. Nej, jag tycker det är väldigt spännande.
Sen kommer det här som gör mig förvirrad och väldigt många andra enligt internet.
När de har pratat om den här start-transition eller use-transition-hucken så har de sagt att här har vi visat hur man ska göra det
Men det är förmodligen inte här ni kommer att använda use-transition, utan den kommer att ligga på en högre nivå egentligen
Alltså typ på routernivå, när du byter mellan routes till exempel
Eller liknande, och på en lokal nivå eller vad man ska kalla det här i den här komponenten
Så ska man istället använda den här use-deferred-value
Och den har liksom aldrig demats egentligen.
Jag tänkte att jag skulle testa det här i samma demo som de körde det här med DNA-bubbelgrafen.
Men det visade sig att de som har gjort den har typ paywallat den datan som laddas in i den bubbelgrafen.
Undrar de det för att det här demopresset är populärt? Förmodligen.
Men så gick inte att testa.
Men som jag förstår det så ska den hooken, det den gör är att den tar bara in ett, liksom en parameter eller ett argument i när du anropar hooken
Och det ska vara det state värdet, så att i det här fallet då så är det typ da eller slider värdet som blir
Deferred, nej det blir såklart värdet på bubbelgrafen som den renderar
Så den stoppas in i just deferred hook och sen parenteras det och det här värdet som ska stoppas in
Och sen spottar den ut sig då ett annat värde som ska vara "deferred"
Det vill säga att det är ett värde som React vet att det här värdet är inte akut att det uppdateras
Och då ska det funka egentligen på exakt samma sätt som vi pratade om med start transition
Men det ska liksom bara vara en hook som du stoppar in ett värde i, får ut ett värde som kommer uppdateras när den hinner
Så att man som användare sätter det från olika håll?
Ja.
För att Transition prioriterar alltid det här?
Nej vänta.
Nej, båda gör exakt samma sak egentligen.
Start Transition är att du säger att det här inte är en akut stateuppdatering.
Men juste for the value.
Jag tror att en skillnad de pratade om var att start Transition så måste ju du ha access till där du sätter ditt state.
För det är ju "setState"-anropet. Du skickar in en funktion som sätter ditt state.
Då måste du ha tillgång till den funktionen som sätter ditt state.
Medan med "useTheFurredValue" behöver du bara ha tillgång till värdet.
Så den skulle kunna komma från en props till exempel.
Och sen skickar du in den i din hook för att du vet att om den har uppdaterats så kommer det ta väldigt lång tid.
Men då skickar den genom Use Deferred Value som spottar ur sig ett värde som React vet att det är inte akut att det renderas.
Just det, just det. Så det är därför man skulle använda Use Transition på en mer överskådlig nivå.
Medans Deferred Value är till för att använda i barn och grejer som kanske är Prop Drillade Nersaker.
Man ska ju inte Prop Drilla. Jag vet, jag vet.
Prop Drill är ganska nice. Jag gillar Prop Drill.
Har inte opinionen svängt kring det?
Jag vet inte. Jag känner att jag är alldeles för "out". Jag har fortfarande inte lärt mig att använda just memo, just callback och just state-korrekten.
Nej, men det är sånt som kommer. När man springer in i ett problem och man måste göra det så lär man sig.
Jo, precis. Men det är ju att jag har gjort det och fortfarande inte "nailed" det.
- Absolut. Det känns väl ändå som att det "make a sense" liksom.
Att du behöver inte ha tillgång till att kontrollera staten. Du behöver bara hantera värdet.
- Mm. - Ja, jag fattar det. Jag fattar det nu.
Kommer du inte att fatta det om jag sitter där?
- Det är så det brukar vara. - Ja, förstår du. Det är teorin så här.
- Ja, och en grej vi kanske skulle ha nämnt i början, men som jag helt glömde bort,
För att opta in i React-daten måste man byta hur man skapar upp sin root-node.
- Jag vet inte vad det var, create... - Root.
- Create root. - Förut körde man render-metoden på React DOM direkt.
Eller från React DOM så att säga.
Men nu kommer det istället vara en funktion som heter create root.
Och sen så har den här roten som skapas har rendermetoden istället.
- Det känns som att jag har ett läxor här.
- Det förstår jag, men det är helt okej.
Just den grejen är också en grej man inte behöver lära sig.
För att man kommer göra det en gång i en app och sen är det klart.
- Ja, det var som när man skulle byta till Hydration.
När man körde server-side runderat.
Det var liksom en stor grej och sen så fick man ändå inte göra det för någon hade redan gjort det i appen.
Besvikelsen var total.
Ja, det var fan det.
Jag kommer ihåg, sa jag det i början, att React Conf också kommer upp nästa vecka tror jag.
Och då gissar jag också på att vi kommer få höra lite mer om React 18.
Och det kommer förmodligen komma ut lite mer väl genomtänkta presentationer av de här features vi har pratat om.
Jag tror det är den åttonde om jag inte minns helt fel. Det kan vara nionde också.
Och det är också remote och gratis. Så vill man kolla så kan man alltid gå in.
Allt kommer ju upp på Youtube efteråt om man vill kolla i efterhand.
Som även jag brukar göra.
- Ja, det är svårt om det är på arbetstid.
- Ja, det är typ om man slår igång det lite på sidan av.
Men det är alltid svårt att fokusera och då blir det liksom bara
halvmesyror av alltihopa.
- Ja, alltså jag sitter ju 100% mobb och pratar med andra människor.
- Du kan ju köra igång det där på sidan och sen bara "ni kan lyssna på den här presentationen"
De kommer bli superglada i ditt team.
Verkligen.
Som sagt, det kommer en massa mer saker efter React 18. Nu har inte vi insett att vi inte har jättemycket tid kvar att prata om det.
Kommer det några serverside-grejer i React 18 nu eller är det "deferred"?
Det är en bra fråga. Det kommer kanske lite grann med Hydration.
Jag har inte stenkoll på exakt change log, jag har mer plockat upp saker jag tycker ser intressanta ut.
Jag hade för mig att jag läste någonstans om suspensgrejen, den sköt mig ju på för att det blev en viktig sak med just service side-renderingen, hur skulle det funka.
Och det sköter mig ganska långt på så tycker jag läste någonstans att man inte bör använda API-produktion för att API-produktion kan nog komma ändras ganska mycket speciellt i och med React 18.
Men det kanske bara var rykten.
Jag kollade diskussionerna på React Working Group lite snabbt och skummade rubrikerna.
Och här finns det ett inlägg som heter "New Suspense Server-side Rendering Architecture in React 18".
Wow.
Första meningen är "React 18 will include architectural improvements to React server-side rendering performance.
These improvements are substantial and are the culmination of several years of work."
Just det. Så det kanske igen är mer bakomliggande saker och själva features kommer senare då?
Det verkar lite så. Det står att det mesta är behind the scenes.
Det finns några opt-in-mekanismer som man behöver veta.
Särskilt om man inte kör något ramverk ovanpå React.
Så det kommer någon nytt API som heter "Render to pipeable stream" till exempel.
Som tydligen ska vara sjukt nice då.
Enligt den där korta texten skummade precis.
- Toppen!
Just det, hade de inte någon namn på den förra arkitekturgrejen som var i 2017? Var det React Fiber? Eller var det i 2016?
Nej, 2016 kom väl React Fiber tror jag.
Och det var ju den nya arkitekturen för deras virtuella dom typ egentligen.
Just det, det var det. Så 2016 var också rätt mycket bakomliggande. Stora ändringarna var bakomliggande.
Jag menar 17 var för att det skulle bli lättare att uppdatera sen.
Och att man även ska kunna köra olika versioner av React i samma app.
Yes, exakt. Det stämmer.
Och sen kommer jag inte riktigt ihåg när Hooks kom.
16. någonting tror jag.
Var det typ 16.7?
Nja, det känns sent.
Ja, minns ej.
Jag vet inte, jag är verkligen bara...
Det är det jag gillar.
Ja, men det jag tänkte säga innan vi avrundar här är att det kommer lite andra coola saker som att de håller på att bygga ett cache API som ska kunna användas tillsammans med suspense.
De håller på med React Server Components som är att du kan köra vissa komponenter i klienten och vissa på servern på ett jävligt coolt sätt.
Det är så pass att komponenten i sig kan ha tillgång till Node-API, så du kan direkt ansluta till en databas eller läsa filer i en komponent om du vill.
- Det var det avsnittet om. - Just det, det pratade vi om i ett avsnitt.
Vi kan länka dit också.
Sen kommer jag inte ihåg om det är något mer nytt som är på G, men vi återkommer väl annars när det dyker upp saker.
Ja, för man kan ju tänka att vi pratar om mycket olika kodar, men det är ju React som är vår stora hjälte.
Så är det ju. Men det är också för att det är där vi kan.
Vi skulle ju lätt kunna prata om andra saker, men det skulle inte bli så jävla intressant.
Nej.
Nej.
Jag tänkte säga någonting självnedvärderande där, men jag ska inte göra det. Jag tränar.
Bra jobbat.
Nu slutar vi på topp idag, med att du inte nedvärderar dig själv.
- Jag gör det i mitt huvud. - Då är det dags att lägga på.
Kul att ni har lyssnat idag. Vi babblade på om React.
Har ni några andra frågor eller vill oss något så finns det på Twitter.
Recensera oss gärna på iTunes.
Med det så säger vi väl hej då för idag.
- Glad andra advent och sånt. - Det blir det.
Vi hörs igen om två veckor.
Så säger vi så.
– Ja. Hej då. – Hej då.
[Outromusik]
