17. Recoil och JavaScript-innovationer
lyssna!
Vi pratar om biblioteket Recoil för att hantera state i React. Therése tycker det hittills känns väldigt bra och lär oss allt om atomer, träd och selektorer. Dessutom Antons relation till ordet “ortagonalt” och en diskussion om innovationstakten inom JavaScript-communityt.
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:
På östgötska: Vilka är backend:ares favoritleksaker?
Docker
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att
klicka precis här :)
Jag får ta det på östgötska tror jag.
Okej.
Vilka är backändarnas favoritleksaker?
Jag vet inte.
Docker.
Åh!
Att man inte ens kan gissa det där.
Man borde ändå kunna tänka "backändarna".
Nej, bra! Jag tyckte det var bra.
Bättre på östgötska.
- Bättre på svenska, definitivt.
- Japp.
- Men, ja.
Jag tycker det... Du har sagt att ni mår ner, och jag vet inte om jag håller med här riktigt.
Jag tror att det här var bättre än förra veckan.
- Ja, men det går... Om jag kommer på ett nytt...
Alltså, jag har ju inte grävt mig ner i de riktigt nödmässiga skämtena.
För jag har kommit på några nya.
- Ja, men det är bra. Det är bra.
Okej, välkomna till ett nytt avsnitt av ASTF.
Jag är mest nyfiken på att du ska prata lite om Recoil, som är ett javascript-ramverk, bibliotek, jag kommer aldrig att ihåg exakt vad skillnaden är.
Nu vet jag nog inte exakt vad definitionen de har, men det är väl ett javascript-lib för React-state-hantering, i beta just nu, tror jag fortfarande.
Och kommer också från Facebook från början va?
Ja, det känns som att jag borde ha pluggat på det här mer om jag skulle prata om det.
Men jag tror i alla fall att en som jobbar på Facebook har lagt grunden för det och skapat det.
Och försöker nu open sourca det tillsammans med några andra.
Just det. Ja men det är ju spännande. Och du kör det i produktion nu eller?
Inte i produktion, ska jag väl inte säga, utan den applikation jag siktar på nu är ju inte släppt live än.
Men vi bygger ju med det. Vilket är vågat, här har ni en beta.
Det är också så jävla svårt, React Native var inte det typ beta tills typ nyss?
nyss. Kanske jag blandar upp det med något annat, men jag vet att det finns någon väldigt känd ramverk
tror jag som var beta fram till jättelänge och alla använder det i produktionen ändå.
Och det är svårt att avgöra, är produktionsredo fast det är beta, bara att de vill ha möjligheten att göra
breaking changes?
Eller hur då?
Ja, alltså kan det mycket väl vara.
Men jag har väl...
Jag är fortfarande ganska ny inne i det här projektet
och jag har väl bara lite tartrat på det.
Och är väl kanske inte den som sitter på allra bästa erfarenhet
men det jag har gjort hittills är
fruktansvärt nice.
Det är liksom...
Ja, det är väldigt lätt att jobba med, skulle jag säga.
lätt att jobba med, skulle jag säga.
På vilket sätt? Jag tänker om man kanske jämför med
Redux, bara för att slänga ut något.
Redux är stort. Redux måste du tänka på flödet hela tiden och
i vilken ordning du gör allting. Du måste se till att göra alla
grejer och du renderar om hela statet. Du måste koppla upp
koppla upp komponenterna och nu har jag i och för sig inte använt Redux med hooks ska jag säga, så jag vet inte hur mycket lättare det är nu, men det är en mycket större grej skulle jag säga, för att recoil det är bara så här, jag drar in en hook, drar in ett state, klar.
Så jag tänkte speciellt på den när jag hade ett problem där jag satt på två olika komponenter som skulle rendera saker på samma state.
Och när jag först satt där och funderade på det här, det här är ju stökigt, det är inte omöjligt, men det är stökigt.
Men då hade jag inte tanken på att Recoil bara fixade det åt mig.
Men det vi kan göra är väl, han som släppte det här har ju en awesome presentationsvideo på vad det är för någonting som vi kommer att länka.
Så den går ju helt klart att kolla på. Och det säger ni kanske inte hundra rätt, vem vet, ni får rätta er om det är så.
Men hela tanken är ju att du har alla dina komponenter,
och det Rieck har lärt då, det är liksom atomer, kallar de det.
Så om man säger att man ritar upp ett komponentträd i 2D,
då skulle man säga att atomerna ligger som ortogonalt rakt upp i rymden ovanför.
- Det här "ortogonalt" är ett ord inte relaterat jättetankt till, ska jag kalla det.
- Sorry, det där kommer nog från gamla matte.
med 90 grader upp, liksom. Rakt upp.
Du har ett x-plan, ett y-plan och här kommer ett z-plan.
Rakt upp från pappret.
- Okej, så om vi har papper på bordet och vi har ritat ut det här,
så ligger atomerna liksom parallellt med komponenterna fast i en rymd ovanför.
- Ja. - Alltså rakt ovanför bara.
- Det känns verkligen som att jag inte borde ha använt det här
som sättet att tänka på överhuvudtaget.
Men ja, rakt ovanför. I rymden ovanför.
Och det jag kan göra är att alla komponenter som vill bry sig om det här specifika statet som finns i atomen, de bara kopplar upp sig mot den.
- Okej, så den har liksom ingenting med komponentträdet att göra egentligen?
- Nej. - Alltså den ligger liksom inte längre uppe i komponentträdet, så att säga?
- Nej. Det du har tror jag väl, nu har jag faktiskt inte kollat dig i projekt, men du har väl en recoil root i projektet, men där ska du bara ha en recoil root liksom.
root. Så det är inte som ett kontext API där du ska wrappa delen av
komponentträdet nödvändigtvis i som du vill kunna nå kontextet i, utan
det är verkligen de flyter här uppe ovanför dig och behöver du använda dem
så huckar du upp dig mot dem.
- Ja, okej. Låter ju rätt smidigt. Men sen, jag är också väldigt så här,
hur stor blir skillnaden mot andra liknande statehanteringsbibliotek?
- Ja, jag tror de pratar, det finns tre anledningar till att de skapar det här.
Och nu har jag nog glömt bort dem. Jag har glömt bort det första.
Första tror jag var den här enkelheten i kopplingen och till exempel för
på kontext är det mycket, mycket svårare att få alla ändringar och rendera
performant om du inte vet hur många komponenter du har från början.
- Ja, precis. För det är ett problem, alltså så här, för det blir väldigt, väldigt populärt
att göra typ en mini-redux till exempel med att köra en use-context och sen
kör man en typ en use-reducer som du skickar ner dispatch-funktionen och så
kan du ha liksom, du behöver inte dra in hela redux men du får ungefär den
funktionaliteten. Men problemet med kontext är väl just att så fort du ändrar
status renderas alla komponenter om som beror på det.
Ja, precis. Och speciellt om du bara injektar en ny uppe i det här trädet, då måste allting
renderas om igen. Och det behöver du ju inte med recoil, vilket var väl en av
anledningarna till att de skapade det. För att du vill kunna få status på olika
ställen och rendera om det på ett performant way. Hans exempel i videon är ju
till exempel att kunna ha interaktion med Canvas.
Just det.
Och det kan du inte göra om du sitter fast i jättemånga omränderingar,
för det blir alldeles så slött.
Mm.
Och sen så, den andra anledningen är väl "using derived state".
Och det är väl hans exempel, jag har verkligen inga egna exempel,
så jag tar bara hans exempel, men är att han har en bounding box
runt olika komponenter och den kan förändras beroende på hur man flyttar
komponenterna i. Då kanske man i vanliga läget tänker att jag har ett state
för boundingboxen och hur stor den ska vara och koordinaterna och allt sånt.
Men det betyder att varje gång du flyttar någonting så måste du också
uppdatera det här statet hela tiden. Du måste hålla koll på att du måste
räkna om det statet varje gång. Med recoil då är det, jag tänker att du ska
deriva state istället. Du kan också skapa selektorer i Recoil istället för bara atoms.
I selektorerna kan du plocka in andra state och returnera ett värde.
Då kan jag plocka in de här komponenternas state och använda dem för att
kalkylera ett värde för boundingboxen, vilket gör att jag aldrig behöver
hårt sätta ett värde för den utan den beräknas av sig själv.
Just det. Det känns som att alla deriverade värden har blivit mycket mer
populärt som koncept också. Jag tänker på det för att det finns också väldigt tydligt
som koncept i Overmind. Där man kan liksom säga att den här
propertyn i det här statet är en derived istället.
Och då är det också samma sak att den tar istället in en funktion
där du spesar att okej, du får in hela staten så kan du spesa att okej, gör det här och så returnerar vi det värdet.
Och då räknas den bara om den delen av statet ändras liksom.
- Ja, det är väl tankarna också. Jag tror det gör en memois, eller kan göra en memois runt.
Jag menar, det är ju jävligt rimligt när man börjar tänka på det, lite objektivt utifrån tycker jag.
tycker jag, för att du vill ju ha en single source of truth. Du vill ju inte ha flera som du försöker uppdatera på rätt sätt samtidigt.
- Nej, men verkligen. Till exempel när jag suttit med lite grann med WebGL och React Free Fiber, som vi pratade om i något avsnitt, då är det också väldigt så här att
när man tänker performance-mässigt, att det går liksom inte att ha statet att vi renderar om komponenterna, utan där måste man också lägga
Jag tror att han som gjorde React 3 Fiber, eller kom på mig det,
han för mig, tyckte Recoil var väldigt coolt när det kom.
Så jag tror att de har tagit fram någon egen variant som passar dem själva lite bättre,
men med samma idéer.
Just för att det funkar så jävla bra tillsammans med,
till exempel WebGL som måste renderas om så jävla ofta.
Men där du inte vill att statet kanske går genom React på just den biten.
Men där du fortfarande kan använda det i React.
Så jag tror att det där funkar också väldigt bra,
Det är väldigt bra, precis som du sa med canvasen.
Ja, men det är ett riktigt bra exempel för det är ju omrenderingstungt.
Jag menar att bara ta, du ska visa den här texten och den här bilden på den här sidan när en användare går in.
Det är inte så renderingstungt.
Är det det? Då är någonting fel.
Ja, men exakt.
Jag tycker det är väldigt spännande. Jag tycker också det är lite intressant.
Jag vet inte när Recoil kom, om det var ett år sedan.
Var det i våras någon gång?
Det känns som att det inte var under pandemin.
Det är min uppfattning.
Men det kanske var tidigt i våras, jag vet inte.
Det är oklart. Vi kan googla lite snabbt medan vi pratar vidare.
Men det jag också tycker är ganska coolt är att det fortfarande kan dyka upp nya idéer.
För mig känns det som att JavaScript har funnits länge.
React har funnits relativt länge.
relativt länge. När det är open source-röster, 2015 kanske.
- Ja, 2014-2015 kanske.
- Och ändå att man tänker att det finns den här bilden,
att det kommer nya bibliotek och ramverk för jag och skriptetiden.
Men det är för att det är en sån jävla innovationstakt.
Alltså det är att folk kommer med nya idéer.
Sen är det inte alla de här idéerna som fastnar, uppenbarligen.
För vi har inte så många stora ramverk.
Och om man tänker så här, React har varit stort då i fem år.
sen det open sourcedades. Jag tycker inte det argumentet håller kritik mot JavaScript, ekosystemet.
För JavaScript, det finns React, det finns Vue, Svelte kommer lite grann, Angular, glömmer alltid bort.
Men det finns ju de här och det är det som gör att det är ganska roligt att jobba i också.
Ja, så är det ju absolut. Men jag förstår ju ändå, jag menar, innovationstakten är väl hög för det finns otroligt många som jobbar med det och rör en del på sig som måste en annan del röra på sig.
Jag hade precis, jag satt och brottades med förra veckan, att jag ville testa Tailwind i ett Create React App-projekt jag satt i.
Tailwind kom ut med 2.0. Tailwind är det här CSS-klassbiblioteket.
Ja, typ utility-klasser liksom, som man komposer ihop eller använder tillsammans för att bygga komponenter.
Ja, så jag ville bara testa det, dra in det och se hur det kändes liksom.
Och då insåg jag ju också att när de släppte 2.0 tror jag, så ändrades post-CSS-versionen som behövde användas tror jag.
Och det var fixat för en del, och Next.js och så, men inte för Create React App än.
Men det ligger uppe på en PR tror jag. Och sådana grejer.
För att de innoverar det och släpper en ny sak, då måste de som använder det eller
dependerar på det eller gör andra saker som påverkar helt enkelt, då måste ju de röra på sig.
Det blir ju som en synergieffekt.
- Ja, så är det verkligen.
- De innovererar.
Så det blir mer bara för att börja med en jävel.
Då gäller det att alla andra rör på sig också.
Ja, men typ.
Ja, men jag tycker det är spännande.
Det är liksom så stora avvägningar som man måste göra.
Till exempel CreateTrackedApp som du tar.
Väljer man att använda det, det är jävligt smidigt.
Men då blir det kanske att man inte kan ligga i the edge of the edge.
Du kan inte vara helt längst fram på kanten och jobba med de absolut nyaste grejerna.
För att du har ett beroende på den.
Jag bad på någon annan liten grej som släpptes häromdagen.
Det var Snowpack, om du vet vad det är.
Det är också, tänk dig, det är version 3 som släpptes nu.
Men det, man kan väl beskriva det som typ webpack för att förenkla väldigt mycket.
Men det är liksom väldigt mycket andra idéer.
Det bygger väldigt mycket på nya ES-modules, specifikationer.
Det vill säga att du kan köra moduler i browsern och sånt.
Och i version 3 som kom släppte de en jävligt cool grej där man kan
typ streama npm-paket.
Alltså, du behöver bara köra importen i koden och du behöver inte npm-inståla någonsin.
Oj.
Utan du bara pekar ut en npm-paket som du vill ha och så funkar det.
Och ska även funka med tooling.
Så till exempel för VS Code så drar de ner typ typer och sånt.
Så att du fortfarande får autocomplete och sånt.
Jag har inte hunnit testa den, jag har bara sett att det kom så jag vet inte hur bra det funkar.
Men det låter ju också som att det är jävligt mycket framtiden på något sätt.
Ja, verkligen. För då skulle man kanske slippa hela de här tree shaking-grejerna.
Och sen hur hanterar de versioner? Det kanske du också skulle slippa. Det är spännande.
Ja, jag tycker det är väldigt spännande.
Jag vet att Denno, alltså Node-varianten,
varianten. Alltså han som skapade Node skapade en ny variant på Node som heter
Denode. Men de tror jag också har samma princip att du ska kunna
bara spesa ett paket genom en import och skriva typ en URL och så importerar den
åt dig. Och det är ju väldigt spännande.
Sen var det många som gav lite kritik om att okej, men då blir det kanske
enklare att få in infekterad kod och sådana grejer.
Det är säkert en ganska vettig approach, men det gör inte så stor skillnad.
- Nej, det beror väl på hur mycket...
Är jag alltid i runtime utan kontroll, då kan det gå åt helvete.
- Ja, exakt.
- Men jag har verkligen ingen inblick, så jag ska väl kanske...
Nej, för det här känns ju... Jag tror att i Snowpack så var det så att när du byggde den, då drog de ner paketen.
Det var inte så att du körde ner paketen när du laddade sidan, så att säga.
Nej.
Utan jag tror att det var att, okej, när du kör lokalt, då streamas paketen, när du utvecklar.
Och sen när du kör ett produktionsbygge, då drar de ner paketen och så sätter de den och så finns det i koden.
Och det är väldigt likt Node-modules-principen.
Ja, det är väl mer en bättre developer experience egentligen.
Ja, exakt. Det är mer att man slipper hela NPM-instål och man kan ändra.
Det är väldigt skönt att "oj, jag behöver bumpa det här paketet och ändra det i koden. Jag kör ingen NPM-instål."
Och så fortsätter man köra.
Så jag tycker det är väldigt spännande faktiskt.
Men det känns som att det händer så jävla mycket.
Ja, det gör det ju. Det är kul att vi ändå pratar om det.
För jag känner ju att jag blir trött bara att vi pratar om det.
Det finns alltid så himla mycket att lära sig och så lite tid eller energi ibland.
Jag har ändå blivit taggad på att testa lite recoil.
Jag har varit lite skeptisk mot det utan egentligen någon anledning.
Jag vet inte riktigt varför.
Kanske för att jag har varit så nöjd med Overmind.
Men jag har alltid varit lite skeptisk mot det.
Löser det här verkligen så stora problem eller blir det så mycket bättre?
Men det känns ändå som att din presentation här, att jag ska i alla fall labba lite med det.
Jag tror det fortfarande finns några saker. Det är någonting med memoriseringen,
att den inte uppdaterar, vilket är bra i att spara beräkningskraft och sådana saker.
Men det var någonting med att det finns en problematik kring det.
Jag kommer inte ihåg exakt vad, men jag tror att det var en issue på det,
att de tittade på det. Så det är klart att det finns saker som inte är 100% lätta.
Man använder det genom att dra in state.
Då kan jag ha use recoil state.
Det betyder att jag får ett värde och en setter.
Jag kan också göra bara use set recoil value.
Då får jag bara ut en setter.
Och så kan jag ta use set recoil state.
Ger mig en setter bara.
Use recoil value ger mig en läsning av statet bara.
Dra in det som en hook.
Och sen så använder jag det.
Och så kan jag stoppa in en dependency array på en ljuseffekt om jag vill göra det.
Eller titta på det.
Och det är jättefort.
En del jag kanske orat mig för är väl att
helt plötsligt så har du det här statet på många olika delar i applikationen,
med många komponenter, så har du ingen kontroll på det.
Och det tror jag fortfarande skulle kunna vara en
en rejäl
grej om man är rädd att ha väldigt
stökigt eller många dependencies i en applikation. Det tror jag är svårt att göra någonting åt.
Men det är lightweight, det är snabbt, det känns otroligt intuitivt. Jag tycker det är väldigt trevligt att jobba med.
Jag har nog inte jobbat med någon trevligare statehantering egentligen. Nu har jag inte provat Overmind.
- Ja, exakt. - Overmind bara.
Men ja, är jag glatt överraskad.
De pratar också om att du kan få ut hela statet, vilket gör att du kan spara olika state i olika urlar, så att du kan skicka specifika renderingar av state.
- Just det. - Och sånt.
Det har jag inte kollat så mycket på, men det är ganska najs också.
Ja, för det känns ju som att, just i och med att Overmind som vi pratar om nu, det känns som att de har ganska olika approach.
Jag tycker att Recode tar den här idén om att man ska co-locata, det vill säga att du vill ha...
statet ska leva så nära som möjligt som där du använder det.
Och jag älskar den idén egentligen.
Lägg din styling så nära din komponent som möjligt, lägg dina grafikquery så nära din komponent som möjligt och så vidare.
Där används liksom... Och samma sak, jag tycker att...
I teorin har jag också upplevt att det är nog en bra idé för state också.
Men när jag har kört Overmind så har det varit så jävla lämpligt att...
För den är liksom åt motsatt håll.
Den säger att "Okej, du har ditt state på ett enda ställe"
"och det är ett enda state-träd som du kan mutera hur mycket du vill."
Och det är liksom så det funkar bara.
Och liksom, ju mer jag har tänkt på det, ju mer har jag tänkt så här
"Ja, fan, det är ganska skönt att ha all state på samma ställe"
"för då kan jag få en så enkel överblick över det."
Det känns som att det måste vara svårare med Recoil där det liksom är...
Men som du säger, det är liksom utspritt så här
"Okej, men har jag det här statet? Hur var det nu? Skapade jag upp det här borta? Hur såg det ut?
Måste man hoppa till den komponenten så kanske gjorde det om jag skulle behöva det statet på ett annat ställe sen också?"
- Ja, men däremot, jag menar alla state-komponenter, eller alla tomra selektorer kan du ha på samma ställe.
- Ja, men det är sant.
- Och de behöver ju typ arkiv till default state.
Och sen så kan du ha dem i samma fil och få en överblick av vilka state du har.
Sen så typar vi upp allting så det är också väldigt tydligt vad som finns där.
Så det tycker jag ändå ger en bra överblick.
Jag kan också ha så här,
ja men här borta har jag ett litet ekosystem eller ett eget träd
och skapa en state field som bara det trädet använder.
Så att det känns inte problematiskt tycker jag.
Ja men det låter ändå vettigt faktiskt.
Jag är väldigt sugen på att testa och se hur det funkar liksom.
Jag tror att det är så. Det känns också som att API-ytan, hur mycket funktioner det finns, är väldigt liten.
Det lockar mig enormt. Ju mindre API-ytan ett bibliotek har, desto mer lockad blir jag användare.
Här finns det atomer, selektorer och några hooks.
Det måste vara väldigt enkelt att lära sig vad allting är.
Det är bara det här du behöver komma ihåg.
Ja, för att det tog inte så lång tid att komma in i det.
Återigen, jag har ju scratchat ytan.
Jag vet inte hur mycket mer som finns där under.
Men att bygga saker i det gick ju jättejättefort.
Jag kommer ihåg att jag såg recoil och sen så var jag nog bara så här.
Och sen så stoppade jag det åt sidan och tänkte inte på det.
Det tänkte jag nu, det får dyka upp om det dyker upp.
Jag vill mer så här, du är mer, det här är nytt, jag måste prova.
Jag kanske orkar lära mig det här när det börjar bli tydligt.
Ja, exakt. Eller när du måste jobba med det.
Ja, precis. Och då hamnade jag på det här.
Och då var första frågan, då var det så här,
vet du vad recoil är?
Och då visste jag nog inte då.
Och när jag började titta på det så insåg jag att jag hade sett det.
Men det hade försvunnit i huvudet.
Så jag är väldigt glatt överraskad.
Ja, men det är spännande. Vi får kanske köra en uppföljning på det här sen och jobba lite mer med det.
Och se om den här smekmånaden håller i sig.
Eller om vi tappar något, eller om det dyker upp något som är en dealbreaker.
Ja, det gör det säkert. Gör det inte alltid det?
Jo, det brukar väl göra det. Det är väl alltid något som dyker upp.
Eller gräser till lite gröna på andra sidan staketet, eller vad fan man säger.
- Staket? - Nej, staket är det nog inte.
Staket känns också som att man ser igenom gräset.
- Där grävde han det där. - Jag trodde på andra sidan vägen.
Ja, det där kanske.
Med den oklarheten så kanske vi rundar av det här avsnittet.
Vill man ha oss finns det på Twitter. Länkarna finns i beskrivningen.
Ge oss gärna en recension på iTunes. Då blir vi glada.
Och hör gärna av er till Anton om jag hade jättemycket fel.
Så berättar han det för mig.
så kan vi pudla i ett vanligt avsnitt.
Japp!
Vi ses så länge!
Det gör vi. Hej då!
Hej då!
[Musik]
