48. The Year of State Machines
lyssna! 
Anton pratar om sin senaste förälskelse XState och gör sitt bästa för att förklara både hur det fungerar och vad dess storhet är för Therése. Det blir state nodes, transitions och events. Ett trafikljus. Ett litet sidospår om useReducer. Hur state machines tillåter en att visualisera och samarbeta kring kodens logik.
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 blev det aldrig några typer i frontend?
Fick aldrig till något riktigt flow.
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 blev det aldrig några typer i frontend?
Jag vet inte.
Du fick aldrig till något riktigt flow.
Okej, det var kul ändå.
Det hade varit roligare.
Jag tänker att det är roligare för de som jobbar med flow.
Ja, kanske.
Är det någon som jobbar med flow?
Jag vet inte.
Facebook har väl kvar det någonstans fortfarande?
Jag tror att React-kodbasen är skriven i Flow fortfarande.
Jag är inte helt 100% men den har varit skriven i Flow i alla fall.
Sen vet jag inte om de har migrerat.
Men jag har inte hört något om det.
Jaja, välkomna till ett nytt avsnitt av ASTF.
Idag är det återigen ett sånt här avsnitt när jag blir kär i någon ny teknik och sen måste få ventilera om den till dig Therese.
– Toppen! Det är så här jag lär mig saker. – Det är de vi älskar allihopa.
Vi har ju något avsnitt väldigt tidigt i poddens historia som heter "Overmind" när jag pratar om statebiblioteket Overmind.
– Med "å" såklart. – Eller "Overmind".
Jag tycker att det ska vara med Åh, det är för svenskat.
Och den kan vi också prata om i ett avsnitt.
Jag kanske har nämnt den en gång, att jag har tappat lite av den.
Men det är också för att den inte maintainas längre så aktivt.
Jag hänger lite på deras Discord och det är väldigt mycket frågor som är där.
Kommer det här biblioteket att uppdateras någon mer?
Men vi får väl se vad som händer.
Jag tror att han som har byggt det från början som heter Christian Alfonis.
Jag tror att det är en norsk som håller på att lämna det över till någon.
Så vi får se vad som händer med det.
Men idag är min senaste förälskelse State Machines.
State Machines i Javascript framförallt.
Och då också bjuder jag på biblioteket X-State.
Du säger herregud.
Så en maskin som trycker ut statusar baserat på informationen den får in?
Typ så ja. Det baseras på något som heter Finite State Machines.
Som är något skitgammalt koncept. Minns inte riktigt exakt när det uppfanns.
Men det finns en massa gamla forskningspapper på hur det här ska fungera.
fungera. Det som det innebär då är att just när det är en finite state-maskin så innebär det att det finns ett
begränsat antal states man kan hamna i.
Så att det liksom inte dynamiskt antal states eller vad man kan gå någonstans
utan allting är specificerat att okej, men från det här statet kan det gå till det här statet och från det statet kan det gå till det nästa statet eller tillbaka eller vad det nu kan vara.
Så att man kan liksom, det går liksom att visualisera
en state-maskin eller en finite state-maskin som en graf till exempel.
Så det är liksom grunden till det hela.
Och sen finns det ju massa saker som bygger ovanpå det här.
Men känner du igen idén så att säga?
Ja, absolut. Den känns väldigt nära någonting bak i bakhuvudet som kom från
hela det här med Alan Turings maskin som var grunden till en dator. Jag vet inte.
Det kan säkert finnas en samband där som jag inte har koll på.
Men det finns ju "Turing Complete" och det skulle säkert kunna vara en state machine.
- Ja, men det där känns väl som en väldigt gammal klassisk grej inom vetenskap och datavetenskap och alla möjliga saker.
Jag greppar ju teorin så att säga.
Inte exakt hur det funkar, men det översiktliga.
Det här pratar vi nog om.
Kanske lite svårt att se vad jag skulle applicera det på i mitt liv.
Dagliga liv.
Det förstår jag, för det är också den frågan jag har fått när jag har pratat om det på andra ställen.
Och man kan ju liksom ta ett litet steg tillbaka.
För det är ju väldigt använt inom spelprogrammering till exempel.
Så finns det väldigt många state machines som bygger på saker.
Det är ett populärt koncept som funnits där jättelänge.
Men har väl inte varit superpoppis inom typ webbprogrammering eller E-React eller vad vi nu kan prata om.
Men om vi tänker att vi har någon komponent.
Vad ska vi ta för exempel här då?
Vi kan ta att vi har en stoppljus, alltså en bil med trafikljus.
Om vi skulle bygga den i React skulle man på ett väldigt naivt sätt kunna säga att vi har tre states.
Vi kör typ "use state" tre gånger.
Så vi har en som är typ "is red", och sen har vi en "is yellow" och sen har vi en "is green" till exempel.
Och sen då skulle man kunna bygga den här maskinen så att när vi, om den är på röd från början, när vi då går från röd till gul,
då sätter man "is red" till "false" och så sätter man "is yellow" till "true" och så vidare.
Och då när man går från gul till grön så sätter man då "is yellow" till "false" och "is green" till "true".
Just det. Och sen kan man konstatera då att när man är på röd så har man bara en väg att gå och det är till gul för du får inte gå till grön.
Precis. Och om vi då skulle modellera det här med "use states" som jag pratade om nu, då skulle det tekniskt sett för det första gå att både gå från att "is red are false" och sen sätter du direkt att "is green are true" utan att hoppa över gula steget så att säga.
Så det är en grej. Plus att du kan hamna i det som kallas för "impossible states", alltså omöjliga scenarion.
Det vill säga att både "is red" är "true" och "is yellow" är "true" om man inte håller tungan rätt i mun när man sitter med sina state-variabler och setters.
Och det är ju för det första inte så nice.
Så här kan man innan man hoppar på Xstate eller state-maskin överlag
så kan man tänka att då gör vi om det här så att istället för att vi har
tre stycken useState-huckar i vår komponent så gör vi om det till en useState-huck
och sedan att den har typ ett sträng värde istället som är red, green, yellow.
Eller en av dem då.
Och då istället för att man ska sätta massa true eller false så sätter vi att
"Okej, men om den är red, då sätter vi den värdet till yellow istället."
Då behöver vi inte tänka på att "Okej, men då kan den vara både red och yellow samtidigt"
utan den kan bara vara ett sträng värde på samma gång.
Och då har vi liksom tagit bort den här möjligheten att den hamnar på en omöjligt state
som inte ens är att kunna vara på, där flera saker är true samtidigt.
Låter det vettigt so far?
Jag är ju mer av en visuell person än en auditiv person när det kommer till kod.
Men jag tror att det är kul att du tar upp det exemplet, för det är ju någonting som kanske man eller jag har gjort automatiskt utan att tänka på att det är därför jag gör det.
Jag använder en sträng istället för att jag inte ska kunna hamna i en situation där jag har två "truths" som inte är tillåtna egentligen.
Det är ett skitbra tips. Även om man ignorerar allt jag kommer säga om statements-
-så är det ett extremt bra tips.
Om man har flera useStates som är booleans-
-så är det oftast mycket bättre att sätta dem till en sträng istället för en sum.
Om inte de här booleansen ska kunna vara true samtidigt, för då blir det annat.
Men oftast är det bättre att ändra till en sträng.
Eller att man kör "use reducer" som gör det lite tydligare vad man ska ändra på.
Så det kan väl vara en varm rekommendation att ta som ett första steg.
Och det man egentligen har gjort är ju just en liten, liten state-maskin. Nästan.
- Alltså det är ju ett sidospår, men jag har ju inte hittat ett case där jag tycker det känns rimligt att använda en "use reducer" heller i mitt liv.
- Nej, men det är ju också lite så här, det är ju typ om man vill uppdatera ett komplext state.
Om du hamnar i en situation där du har flera useState vars värden är relativt relaterade till varann
eller som hänger ihop, så att du kanske, om du kommer på dig själv med att
på flera ställen i din komponent så kör du flera state, alltså useState setters
då kan det vara vettigt att man slår ihop dem till en useReducer och att då
där du tidigare körde flera, där du uppdaterade statet på flera useState-variabler tidigare
Där dispatchar man bara till reducer.
Men som sagt, det kanske är ett cyberspår.
Jag tänker att det skulle kunna vara jättebra när man gör beräkningar.
Ja, förmodligen.
Men som sagt, det beror också lite på...
Jag tänker att det mer beror på hur ditt state är modellerat egentligen.
Alltså om du har en ganska komplex state eller bara ett värde.
Ja, förlåt, cyberspår.
Jag får upp någon så här gammal...
textbaserat äventyrsspel i Python jag gjorde en gång.
För att få upp lite det här att jag stoppade in vilka vägar den här spelen får gå när den har gjort det här.
Och så kommer de här möjliga scenarierna fram.
Ja, jag tycker det är ett superbra exempel.
För det är ju verkligen en state-maskin.
Att du får spesa vilka vägar man kan ta mellan de olika statesen.
Eller rummen om man tänker en dungeon crawler textbaserat spel.
Egentligen är det bara tre saker som en state-maskin består av.
Det ena är state-noderna.
Som i vårt fall skulle kunna vara red, green och yellow.
Det skulle kunna vara våra tre state-noder.
Sen finns det transitions som är vägarna mellan de här state-noderna.
Sen finns det events och det är eventsen som triggar transitions.
Så säger vi att vi har red statet, då kan vi spesa att den tar emot ett event som kanske heter "next"
Bara för att jag inte kom på något bättre
Och då har vi spesat att "next-eventet" triggar en transition till yellow
Så det vill säga att då har vi spesat att från röda statet kan vi gå till det gula statet
Men då har vi också spesat att då finns det ingen möjlighet att gå från röd till grön direkt
Utan då måste man också spesa på gula statet, att den har en transition till det gröna statet
Och att det finns ett event där som triggar den transitionen för att komma vidare
Och det är exakt det du pratar om med ett textbaserat spel, eller vilket spel som helst
Men där man går mellan olika rum och det finns dörrar mellan rummen
Så det tycker jag är ett svinbra exempel.
Det kanske ska vara Snonja som pratar om det här med någon annan.
Okej.
Men känns det som att du hänger med?
Alltså de här tre grejerna.
Du har state noder som är vilka states vi kan stå på.
Sen har du transitions som är övergången mellan dem och event som triggar transitions så att säga.
Ja, alltså jag känner mig hyfsat med på det här.
Och i ärlighetens namn så var det...
Nu är det fan länge sedan, men inte så länge sedan som jag faktiskt kikade lite på det här när en kollega tyckte att det var ett alldeles opportun tillfälle att använda Statement of Achievement,
när vi skulle ta fram olika statisar på objekt. Så då läste jag nog på lite och tänkte att "ja, det här greppar jag nog".
Och sen såg jag kod och rekursiva anrop och grejer.
Och då tror jag att jag backade lite.
Men jag tror han löste det själv som en hjälte.
Och jag bara gick vidare.
- Ja, det kan ju verkligen vara lite avskräckande.
Om man pratar om bara de här tre sakerna som vi pratar om nu så är det ändå ganska straightforward.
Sen finns det ju såklart massa saker runt omkring där också.
Alltså det finns något med state charts som, om jag inte är helt uttryckt här nu,
är att det är när du använder flera state machines och nästlar dem
eller du har hierarkiska state machines eller parallella state machines
eller state machines som skapar upp barnstate machines och sen skapar de upp barnstate machines
och hur de kommunicerar mellan varandra.
Men det kan vi lämna till något fördjupande avsnitt någon gång i framtiden.
Men jag tänker också bara för att man ska fatta vad det kan vara bra för
Ett exempel på en state-maskin som är väldigt enkel att bygga eller som man har stött på är till exempel ett fetch-anrop.
När du kör fetch i din kod så kan det vara att först är det nåt waiting state eller idle state när du inte har gjort din fetch.
Då kan du tänka att det här är ditt promise egentligen.
Sen kan du ha en loading state och det triggas av att du har ett event som triggar det här.
Det är typ "fetch"-eventet som triggar att vi går till "loading" och gör vårt anrop.
Sen kommer den att stå i "loading"-statet tills den har fått ett svar.
Då kan det vara att vi fick ett positivt svar.
Då kanske vi går till ett state som heter "success".
Och så händer det nånting.
Eller om vi fick ett negativt svar, då kanske vi går till ett state som heter "error".
Då triggar det ett event på att anropet inte fungerade.
Sen skulle man då kanske kunna ha att, okej, men om vi är i error-statet så kanske man kan skicka en retry, till exempel.
Ett sånt event till vår maskin då.
Och då kommer den göra anropet en gång till, hamna i loading och sen beroende på om det går bra eller inte så hamnar den i success eller error.
Så det är också ett exempel på en state-maskin som man kanske kan...
Som man har stött på kanske tidigare i någon utan att tänka på att det är en state-maskin just.
Jag får bara upp bilder så här när jag börjar på ett uppdrag.
"Perfekt, jag drar in en states machine!"
Det kanske inte är det första man gör.
Men det finns ändå fall när man vill modellera saker.
Ett exempel på saker som är bra att modellera med states machines är om du har någon typ av flerstegsformulär.
Det brukar vara ett "go to" exempel för många som pratar om state machines.
"Okej, men om vi har ett formulär med flera steg, då kan det vara att i det här statet som är det första
då kan vi ta emot vissa events och de eventsen uppdaterar datan som finns på första steget."
Det är också en grej som kan sägas att våra events behöver inte nödvändigtvis trigga en transition till ett annat state.
Utan maskinen kan ta emot events med data och spara ner information också
På steg 1 kanske vi tar emot att vi har first name och last name på steg 1
Då har vi event som skickas när man fyller i de fälten
Sen finns det kanske en next-knapp på det här formuläret
Då triggas ett event som skickas till nästa state
På den sidan kan man fylla i nästa information som kanske är e-mail eller något
Oerhört dålig UX på det formulärt känner jag när jag pratar om det.
Men det förklarar ändå lite fördelen med att köra det.
För det som händer då är att då kan du se till att innan du har fyllt i first name och last name så kan du inte gå till nästa steg.
Och står du på steg två så kan du inte fylla i first name och last name.
Eller om du står på steg ett så kan du inte ännu fylla i email och så vidare.
Så det är väldigt mycket kontroll över vad man kan göra.
Jag ska säga, för våra lyssnare i Orördrad Radio, men du ser fortfarande väldigt skeptisk ut.
Jag ser ut så här.
Eller vad jag skulle säga.
Jag tror att ditt exempel påminner väldigt mycket om någonting som jag gjorde inte alls för lång tid sedan.
Jag tror att det blir...
Jag förstår grejen och när man väl har implementerat det så är det klart att det lirar väldigt bra.
Jag tror att jag blir...
Känner mig inte skeptisk till det som så.
Jag känner mig skeptisk till hur roddar jag i den här koden?
Går den att förstå? Är den för komplex för min hjärna?
Det är det här som är, i och med att du pratar om att du är en visuell lärare, det här är, och det är kanske nu först vi kommer till det som enligt mig är det absolut coolaste med state machines.
För om vi tittar på Xstate då, som är det här populäraste JavaScript-biblioteket för state machines. Där visualiserar du hela din maskin och vilka states den har, vilka events den har, hur du går emellan dem.
Allting är egentligen bara ett javskript objekt.
Så du behöver inte skriva någon egen kod på hur du hanterar de här.
Alltså hur du går mellan dem.
Eller du behöver inte skriva någon egen kod på hur du faktiskt interagerar med maskinen.
Utan du skriver en specifikation som är typ så här.
Du ger den ett id.
Du säger något initial state som du vill ha.
Och sen så finns det en states property.
Och på den så skriver du vilka states du har.
Vi hade kunnat skriva "red", "yellow", "green" till exempel som tre properties.
De i sin tur är objekt och i de objekten spesar man "on" som är en property.
Och sedan spesar man i den vilka event den kan ta emot och vilket state ska gå till när det händer.
Och det är egentligen allt man behöver göra.
Så att skapa den här "red", "yellow", "green"-maskinen kanske är...
Jag skulle säga 15 rader av ett JavaScript-objekt,
som du sen skickar in till XState och sen sköter den allting åt dig.
Är det här vi äntligen ser den totala vinningen i att ha paket?
Gud ja, det är det definitivt.
Jag skulle aldrig vilja implementera allt som finns i XState själv.
Det är det som är lite coolt.
Det som är ännu mer coolt är att eftersom den är en finite state-maskin som vi pratade om i början.
Det vill säga att det finns ett begränsat antal states man kan hamna i.
Man kan tänka sig att det är som en graf.
Om du har sett ett flowchart någon gång.
Man ritar upp sitt yellow, eller red, så är det en pil till yellow.
Sen är det en pil till green från den.
Sen kanske en pil tillbaka till red från green.
Då finns det verktyg för att ta din XState-maskin och visualisera den.
Du kan klicka på ett VSCode-extension där du får upp en knapp bredvid din maskindefinition.
Där står det "Open Visual Inspector".
Klickar du på den öppnas det ett fönster bredvid din kod där du ser exakt hur din maskin ser ut.
Du ser alla pilar mellan alla olika states.
Du ser hur de går mellan varandra.
Du ser vad eventen heter och hur de triggar varandra.
Plus att du då också kan klicka på simulate.
Och då kan du i din visuella bild av det här,
då kan du klicka på dina events och se vilka states du hoppar till.
Du kan se hur det går mellan dem.
Du kan sitta och klicka runt i din maskin och se hur funkar logiken.
Och det gör ju då att helt plötsligt så är all logik i din applikation
som är byggd med state-machines kan du sitta och titta på och klicka runt i och se hur den funkar
utan att behöva köra själva applikationen egentligen.
Det låter ju extremt nice om det är en bra gränssnittsupplevelse och horribelt om det är bara brus.
Gud vad jävla pessimistiskt det är.
Det får det vara. Vi är tillbaka till avsnitt ett. Det är pepp och depp.
Jag tycker att det funkar extremt bra.
För det som också är att du kan även till exempel aktivera DevTools med XState.
Som gör att när du kör din maskin eller din app i browsern.
Till exempel, jag bygger ju det här Gameshow-projektet och där använder jag State Machines.
Så när jag kör min Gameshow, då kan jag ta upp ett fönster bredvid där jag ser min maskin.
Som är implementerad.
Och jag kan då klicka runt i den och liksom så här, om jag skickar det här eventet.
Då ska jag gå till det här statet.
Då synkar den med min applikationsstate.
Så när jag klickar runt i den visuella bilden av min statemaskin så uppdateras även statet i min app.
Så jag kan istället för att klicka runt i GUI, så kan jag klicka runt i den visuella bilden av maskinen och se hur det påverkar GUI.
Det är också extremt coolt.
- Ja, det är lite som att trycka in CSS-attribut i domen.
- Ja.
Exakt, alltså det är liksom att göra det direkt i browsern liksom och så fast du kan
Nu kan du göra det, det är liksom att du har visualiserat logiken istället för att bara visualisera
Gud kan man säga
Och den sista coola grejen som kom bara härom veckan
Från, det är ett företag som heter Stately
Som han som har byggt Xstate har grundat
Och de släppte då en ny version av sitt VS Code Extension i veckan
Kanske var förra veckan
Där de har gjort en visuell editor
Istället för att du skriver det här javskrivt objektet själv
Så kan du drag and droppa ut dina states, events, transitions och allt annat som man kan lägga på ovanpå
Så helt plötsligt behöver man inte ens kunna skriva kod för att kunna skriva logiken till en app
Så det är en väldigt "no code" grej
Men att du kan liksom...
Egentligen skulle man kunna sitta tillsammans med en produktägare eller en UXare och visualisera hur det ska funka.
"Jamen när vi sitter på det här steget i det här flödet, då ska vi kunna gå dit."
Och så kan man sitta och titta och så kan man sitta och klicka igenom det här och se så här.
"Ja men funkar det bra? Känns det bra? Är logiken vettig?"
"Åh nej, här hade vi inte tänkt på det där."
Och då kan vi fixa det direkt liksom.
Och sen kan man då...
Och sen synkar det direkt till din kod.
Och då kan man liksom bara köra det rakt upp och ner.
Men tänker du att det är så pass, vad heter det, jag vill säga simplifierat men så pass tydligt att en person som inte har kodkunskap kan göra det också?
Ja det tror jag.
Ja.
Det beror ju inte så mycket på det.
Jag tror verkligen det.
Jag tror att 2022 är "the year of the state machine".
Jag tror att det kommer att få en riktig boom när det här nya verktyget som de släppte nu kommer och folk kan drag-and-droppa det.
Man måste lära sig vilka properties som finns på det här jagskriptobjektet som man kan definiera maskinen med.
Betyder det att vi kommer ha en massa state machines där vi inte hade behövt state machines?
Ja, garanterat. Det är väl alltid så när det blir en high.
Du pressar in state machines var än vi ens kan.
Ja, så kommer det till 100% bli.
Men då undrar jag lite, är du liksom, vad är det du tycker är så himla nice?
Är du liksom intresserad av att de facto bygga en state machine eller resultatet state machinen producerar åt dig?
Nej, alltså det som gör mig förälskad i det är ju just det här att logiken kan visualiseras och liksom formaliseras på ett annat sätt.
Jag vet inte, som sagt, om vi tar min gameshow som ett exempel.
Bakgrunden är att man har en gameshow, den kan ha flera segment. Varje segment kan innehålla flera frågor.
Det kan vara olika typer av segment. Vissa innehåller frågor, vissa gör andra saker.
Frågorna kan vara på olika sätt. Vissa kanske är att du visar upp en bild.
Vissa kanske är alternativfrågor där du ska klicka i olika alternativ.
Någon är bara att man ska trycka snabbast på knappen, eller vad det nu kan vara
Och det som jag kan göra då med Statemachine är att jag kan definiera logiken för alla de här olika sakerna
Och bygga samman den logiken till en enda stor klump, i brist på bästa ord
Och att jag också kan, sagt och sagt, se den här logiken
För jag vet liksom inte ens om jag skulle lyckas tänka igenom hur allt det här skulle funka
Om jag inte kunde spesa det i en state-maskin.
Jag hade ju liksom...
Det som jag hade behövt göra är att rita upp en massa flödesscheman.
"Ja men okej, om jag står på den här frågan och ska gå till nästa fråga"
"då ska det här hända, då ska det här statet uppdateras."
Nu får jag det gratis istället via state-maskinen.
Så han säger att "ja men då säger jag att okej"
"från den här frågan ska jag bara kunna gå till nästa fråga"
"och då ska det här hända"
"och då kommer det inte kunna ske någonting annat med mitt state."
Alltså jag behöver liksom inte oroa mig så mycket att jag har kodat fel.
så länge min lilla visuella bild av logiken ser rätt ut.
Fan, umella loss lite bara.
[Skratt]
Nej, skoja bara.
[Skratt]
Ja, men det är väl typ liksom så här,
det sitter man med umellgrejer och sen ska du liksom göra om det till implementation
och däremellan blir det ju ofta mycket missförstånd och förvirring.
Ja, nej men jag förstår, alltså det är väl svinbra att kunna få liksom en
tydlig representation av vad man håller på med.
Det gäller ju det mesta tycker jag.
Bara en sån sak som när den här Bundle Size Visualizer kom.
Ja, exakt.
Har du egentligen ditt projekt?
Alltså sådana delar.
Så det är väl alltid bra att kunna se vad som finns här egentligen.
Ja, så jag kan varmt rekommendera alla att i alla fall testa lite.
Eller kolla på de exemplen som finns.
För det finns ju extremt många exempel på sådana här maskiner.
I alla fall på deras hemsida som är stately.ai tror jag.
eller xstate.js.org
Det är ju ändå lite intressant, för du är mer intresserad av produkten du får ut
än du är av att göra en state machine själv.
Ja, absolut.
Det hade inte behövt vara en state machine om det gav mig samma fördelar.
Men jag vet inte om det finns någon annan alternativ.
Nej, det är bara jag som fastnade vid en tweet som jag ville se om jag kunde fortsätta applicera på livet.
Jag tror det var någonting i stil med att min pappa är en audiofil så han bryr sig om högtalare.
Det spelar ingen roll vad det är för musik eller ljud utan det är bara högtalaren som betyder någonting.
Så kan du vara som utvecklare också.
Du kan antingen bry dig om musiken eller tekniken.
Och musiken skulle då vara produkten.
Ja, den tweeten gillar jag.
Ja, jo, jo.
Men det finns saker att känna med den tweeten som jag kanske inte ska gå in på nu.
Men jag håller med.
Det jag tycker är väldigt bra om jag ska formulera mig extremt kort och koncis så är det liksom att
Xstate eller State Machines låter mig skriva ganska buggfri kod.
För att den sköter så mycket i bakgrunden åt mig och att det blir tydliga gränser mellan olika states och tydliga vägar mellan dem.
Passa oft.
Så nu, till nästa avsnitt, då har du också blivit såld på State Machines när du bara har testat lite. Det är perfekt.
Ja, det får jag absolut göra. Jag ska väl bygga en superfetch, tänkte jag.
Ja, exakt. Du kan komma till ditt team och säga "Du, jag har byggt en fetch här med en state-maskin i bakgrunden".
Jag ska också säga, innan vi avrundar, det finns ju också en massa saker som hur du använder Xstate i typ Vue eller React eller andra bibliotek.
Alltså i React så är det en hook som heter "use machine" och så skickar du in din maskin-definition.
Och sen spottar den ut sig i statet som du är på och en send-funktion för att skicka events till den.
Så det är också extremt simpelt.
Men man kan också använda det utan ramverk och du kan använda det, det finns massa olika varianter på det.
Så det kanske är det sista jag har att säga.
Ja, alltså jag tycker att det låter jäkligt cool och jäkligt...
Cool?
Coolt?
Jäkligt nice.
Och på något sätt så känns det ändå som att...
En del av mig vill känna att det har kommit något nytt och coolt.
Fast det bygger på så extremt gamla principer.
Så det är inte nytt.
Det är bara en ny take på det.
Så jag är egentligen lite spänd på att testa det.
Men också trött.
Det får vi se.
Det förstår jag.
Man ska hellre vila än testa X-Tate.
Eller?
Men toppen.
Vi säger så. Vi finns som vanligt på lite olika sociala medier och sånt där.
Det är bara att höra av sig om man har några frågor.
Annars så tackar vi för oss.
Ja, så hörs vi om två veckor.
Det gör vi. Säg så.
Bye bye.
Hej.
[Outromusik]
