2. Åvermind
lyssna! 
Anton har känt sig extra produktiv när han varit mellan två uppdrag och har i processen upptäckt ett nytt bibliotek för statehantering som han nu bara måste berätta om. Therése å sin sida tycker Typescript suger glädjen ur det snabba och stökiga. Dessutom snackar vi tankebanor när man ska lösa problem, att vara klyftig och onödiga abstraktioner.
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
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Pizza, snacks, det var hemma mycket. Undvika folk.
Ja, och lite trött.
Ja, exakt.
Välkomna till avsnitt två av asdf, eller asdf, som vi aldrig bestämde hur det skulle sägas.
asdf.
Vi tänkte väl, jag har lite grejer jag vill prata om, och sen får vi se om vi är vart för er i landen helt enkelt.
Men en grej som jag kommer tänka på med tanke på hela pandemin och corona och lite sånt där
är att jag har varit rätt produktiv de senaste två veckorna.
Nu vet jag inte riktigt om det beror på den grejen, för jag tänker att jag egentligen kanske har varit mindre produktiv
men jag har också varit mellan uppdrag de senaste två veckorna, typ ungefär.
En och en halv kanske jag blev.
Och har då kunnat jobba på lite hobbyprojekt.
Jag har inte varit produktiv i något annat perspektiv så att säga.
Utan det enda jag varit produktiv i är att jag knackat lite hobbyprojekt.
Men...
Det har ändå varit ganska kul. Så nu är det... Fan, jag har byggt...
Jag vet inte hur jag ska förklara det, jag har liksom ingen pitch på det jag bygger.
För att jag har inte behövt pitcha till någon såklart.
Men för att ge lite kontext, så det jag bygger är typ en...
Hur ska man förklara det? Tänk dig ett rit-gissa-spel.
Där alla ritar och den som gissar är en riktigt kassmaskin i lärningsmodell.
Och sen så funkar det så att man ritar på telefonerna och så ser man på en dator vad alla ritar i realtid.
Och sen så får man poäng och grejer.
Och jag byggde Resmetol-projekt för kanske ett år sedan, eller något.
Lite drygt, jag började nog för ett och ett halvt år sedan på det.
Och har haft en ganska basic version uppe som har varit buggig och som man bara kunnat köra en åt gången,
eller ett rum åt gången, hur man ska få säga.
Och superful design. Alltså det var typ bara vitt och rosa.
Och sen typ Comic Sans text och grejer.
- Det är en klassiker. - Ja, det är en klassiker.
Men sen fick jag fram det nu för att jag fick lite inspiration nu i och med att alla jobbar hemifrån.
Så det är ganska roligt att kunna köra den här på avs och grejer.
Och då tänkte jag att "Vad fan, då bygger jag om den från grunden".
Och tänkte att det var en jävla bra idé.
Men det har ändå gått över förväntan.
Men varför bygga om den från grunden? Varför inte iterera på den du redan hade?
Nej, alltså okej. Det är väl på ett sätt en iteration i det stadiet.
För att jag har ju liksom alla problem jag stötte på när jag byggde den andra har jag ju inte stött på nu då i och med att jag har löst dem redan.
Men koden körde jag om från grunden.
Frontend-bitarna vill jag bygga om för att jag vill bygga den i TypeScript med React
istället för bara React i JavaScript.
För jag har inte kört så mycket TypeScript i React förut och tänkte att det kan vara kul.
Det kan vara bra att lära sig.
Skeptisk.
Vad tycker du om TypeScript i React?
Ja men, alltså jag förstår, alltså, o, det ska också sägas att jag,
lik jag, var väldigt dålig på TypeScript.
Nej, men jag förstår verkligen poängen med det i stora projekt där många är inne och grejar.
Det hjälper en, du hittar buggar och sådana saker, absolut.
Men i ett hobbyprojekt där man bara vill knacka loss lite, tänker jag.
Där hade jag nog kanske inte valt TypeScript.
Jag hade nog samma approach som du innan.
Jag har inte skrivit jättemycket typescript.
Eller, jag skriver en del typescript på backend-grejerna.
Jag brukar ofta köra ett ramverk som heter NestJS, om du känner till.
- Vi pratade om det förra gången. - Ja, det gjorde vi.
- Jättekort. - Superkort.
Men det är ett ramverk som är så här, det finns moduler för allt i det.
Och det är typescript för backend och Node.
Och där finns det ju en WebSocket-modul som är skitnice tycker jag.
Så därför kör jag WebSocket för i all tidskommunikation ändå.
Och den är ju TypeScript.
Och då tänkte jag så här, fan det skulle vara nice att kunna dela modellerna mellan fronten och backen.
Så att när det kommer till fronten så kan jag liksom bara återanvända modellerna där för att få lite typning.
Bara fram och tillbaka. För jag hade ändå lite strul när jag byggde det förra.
Det matchar inte med den fronten och backen.
Jag har missat, skrev jag lite fel på en typo?
Ja, jag fattar ändå grejen. Det är ju smutt.
Speciellt när vi var på Nordicia så såg jag snacket där om
kör typchecking all the way.
Ja, men exakt.
Förr i även någonstans så körde vi GraphQL, så hade vi alla
scheman där och sen upp mot TypeScript och körde och
då vandrade de till interface i TypeScript.
Och allt var typ att hela vägen upp och det funkade skitbra.
Ja, det är ett taket att prata med, då auto-genererade de väl typerna från GraphQL?
Ja, de hade någon... Jag vet inte varför jag tog upp det, nu kommer jag ihåg det så dåligt.
Men det var bra.
Vi lägger en länk i beskrivningen om någon vill titta på det.
Då tänkte jag att det kanske man skulle kunna göra något med.
Jag kan ju inte TypeScript egentligen, så jag vet inte riktigt om jag har gjort rätt.
Men jag har lagt något som heter en "project reference" från min klient till min server.
Så att den har en referens till serverns projekt.
Och då kan jag bara inkludera eller importera modellerna, vilken annan fil som helst.
Från servern liksom.
Och det funkar väldigt, väldigt nice.
Man ska säga. Typescript plus React har växt på mig när jag byggt det.
För jag tycker det är väldigt trevligt.
typa props in till komponenter, sätta vilka som är required eller inte, få Intel-licens i typ VS Code på det.
Ja, det är trevligt alltså.
Ja, tills man bara vill testa någonting och man bara vill få ut någonting, jag kompilerar och får utredningar.
Nej, lint fel, typ skruvit fel, det här är trasigt, jag måste kommentera ut det här.
Ja, visst, men det suger lite glädjen ur det här snabba stökiga.
Mm, men jag håller med egentligen att det suger ur lite snabba stökiga grejerna ur JavaScript,
vilket är mycket det man gillar med JavaScript kanske.
Men jag vet inte, jag tycker att vinsten är nog större ändå.
Sen är det kanske inte att jag sätter mig och kör typeskrift om jag ska köra en dagsprojekt hemma, bara för att testa någonting.
Utan det här projektet tänkte jag ändå att det här ska ändå släppa publikt. Jag vill kunna ha det och jag vill lära mig lite mer typeskrift.
Vilket gjorde till ett ganska bra val ändå, tror jag.
Ja, alltså där är man ju i en helt annan ballpark om du tänker att det här är någonting som ska finnas,
ska kunna ta hem eller lägga pulukvests på och använda, absolut.
Då vill man väl ha mer struktur. Jag är mer, jag tror mycket av anledningen till att jag blev frontend
eller snarare att jag bytte till javascript är för att jag gillar det här stökiga,
jag vet att man sätter sig mycket i skiten och jag har varit med om att produktionen har gått ner
på grund av null och sådana saker, absolut. Men jag gillar det här lite kaosiga.
Jag tror att det är en väldigt bra representation av hur jag tänker allmänt, hur min hjärna jobbar.
Jag är inte någon som någonsin skulle kunna jobba testdriven och göra det bra.
Det är för kaosigt i mitt huvud.
Ja, fastän. Men jag tänker att det borde ändå gå att kombinera dem på något sätt.
Om vi tar testdriven som exempel nu.
Det borde finnas en gillande medelväg någonstans.
–att du skriver ett stökigt test för en stökig implementation?
–Ja, det gör det säkert. Jag har bara inte lagt tid på det.
Jag brukar se det lite som att när jag kodar, det är som att jag tar en härva med trådar eller trassel–
–och så tar jag en och börjar dra lite och så ser jag vad som kommer med.
–Hur mycket du trasslar upp?
Ja, precis. Och ibland så går det åt helvete. Då får man dra i en annan tråd och så får man se vad som kommer upp där.
Lite så programmerar jag.
Jag kan verkligen känner igen mig. Särskilt om man sitter med något jättestort projekt. Då är jag helt på den sidan.
Jag uppskattar jättemycket att det finns tester. Om det finns enhetstester eller om det finns integrationstester eller vad som helst.
Jag älskar det, om du gör det.
Men jag håller med, det är lite kul att sitta med det här helt otressert.
Så ska man ändra någonting och man bara "Vad händer när jag gör det här?"
Ja, men det är inte riktigt så jag menar heller.
Det är snarare att de här kaoset med trådar är problemet jag ska lösa.
Ja, du menar på ett mer abstrakt plan.
Ja, precis. Det kan också hända att man får en tjänst och så ska man bygga någonting.
så drar man någonstans och sen kommer halva projektet med.
Men jag menar med det här problemet.
Jag ska bygga det här. Då börjar jag någonstans och så bara kör jag och så ser jag vad som händer.
Ja, jag förstår. Problemet som du visualiserar dig är en boll med trådar.
Ja, lite.
Och sen drar du i första bästa tråd och ser.
Jag är inte så bra på att se domino-effekten, jag är inte så bra på att se vad som händer när jag gör det här, utan jag måste aktivt se det när det händer, väldigt visuellt.
Jag tror det här är varför jag är så fruktansvärt dålig på schack.
Du säger att du har inget konsekvenstänk.
Du gör saker såhär, det går som det går.
Ja, men lite.
Ja, det är spännande ändå.
För det är lite annorlunda.
Skulle du säga att du är bra på att visualisera problem?
Eller förstår du vad jag menar? Att hålla ett problem i huvudet.
Det finns en jättefint ord som jag inte kommer ihåg nu.
Alltså när man håller många delar av ett problem i huvudet samtidigt.
Förstår du vad jag menar?
Jag är inte helt undrad på om jag förstår vad du menar, men säg att jag ska bygga någonting, då kanske jag tänker på att det här kan ända och det här kan ända och det här kan ända och det här kan ända.
Allt det här måste jag se till, men hur jag ska lösa det, det vet jag inte än, men jag vet att det kommer bli ett problem.
Ja, precis. Jag tror att jag är ganska duktig på att se ett problem och tänka att det här är de delarna vi ska göra.
Och sen hålla alla de delarna i mitt huvud. Att jag håller koll på att det här ska fixas.
Jag håller på när jag jobbar med problemet. Eller att man ska implementera en feature som både är frontend och backend.
Och lite databasändringar och kanske tre olika services i backenden som ska ändras.
Så jag är nog ganska bra på att hålla koll på att vi ska ändra det här, och sen ska vi göra det här, och så ska vi göra det här, och så ska vi göra det här.
Och sen är jag väldigt bra på att även om det dyker upp någonting, att oj nu blev det något konstigt här,
nu blev det ett litet sidospår, så har jag ändå kvar bilden inom mig av vart vi är i problemet och vad som ska hända.
Jag tror att jag kan ha alla delar, men jag är betydligt mer kaosig. Jag är inte sekvensiell, sa jag.
"Det här borde fixas och det här borde fixas och vi gör någonting nu så ser vi vad som händer där."
Samtidigt som jag har lite problem med att "är det här det absolut?"
Eftersom jag är så dålig på att tänka framåt så tror jag att jag har fastnat inom "det här ska bli bra på".
Så då sitter jag och grubblar på hur jag kan bygga det här på allra bästa sätt
och se till att jag täcker alla eventuella framtida problem här.
Och sen till slut sitter jag där och tänker att nu har jag gjort en filtrering på en map
och sen har jag gjort en egen reducer och byggt det här.
Jag bara, det här är skit. Nu får vi backa.
Det är ofta på poängen med en själv om att lösa ett problem i taget.
Får det bara funka och bygga om det sen i sådana fall?
Jag har verkligen kommit till en punkt där jag kan fastna i den här overengineerade grejen.
Jag gillar verkligen inte overengineerade saker.
Jag vill att kod ska vara rimlig och funka.
Men jag är samtidigt så rädd för att någon ska titta på det och tycka att det är alldeles för rudimentärt.
Det är så här dum i huvudet. Varför har du inte lagt in femton reducer och annat ramverk här?
Jag vet inte.
Nej, men det där är ju lite klassiskt att när man börjar som nymedelprogrammerare
så är det ju väldigt lätt att man tittar mot abstraktioner som färdiga lösningar på problem.
Alltså typ design patterns till exempel.
Att man tänker att om jag bygger en abstraktion här som löser oavsett alla framtida problem
Antingen att man har det tänket eller att man kan göra ett "factory pattern".
Om vi behöver lägga till nåt här i framtiden, då kan vi bara lägga till ett "factory".
Och sen händer det där. I 99-fall och 100-fall kommer det aldrig till "factory".
Det finns någon klassisk bild, jag vet inte var den kommer från, där de har gjort olika stadier i en utvecklares liv.
Som precis ny då skriver man "Console Log, Hello World"
Ja, och "if"
Ja, precis. Och sen blir det typ steg två då har man gjort en klass av det
Eller nåt, och så står det "Hello World"
Och steg tre är typ så här att du har gjort ett jävla "Hello World Factory" och fan vet allt som bara loggar
Och steg fyra då, då är det bara "Console Log, Hello World" igen
Och jag tycker den är verkligen liksom klockrent
För att det känns faktiskt som att man kommer tillbaka till att okej
När man har kommit en viss bit och kommit in och tillbaka, men jag vill ha det så enkelt som möjligt.
Gör inte för tidiga abstraktioner.
Nej, det där har jag med mig.
Det är nog inte exakt samma exempel.
Det är någonting med någon if, tror jag.
Som nybörjare har du en massa ifar.
Sen går du vidare och då blir det någonting jättekomplicerat.
Det kanske blir någon typ av factory. Jag kommer inte ihåg exakt var.
Sen sista steget när man är mer senior, eller vad man vill kalla det på den här bilden.
på samma sätt, att man har gått tillbaka till det mer grundläggande.
Vi behöver inte hålla på över komplicerade saker.
Jag har med mig den så himla mycket, speciellt när jag hamnar i projekt som är väldigt
komplicerade för att göra väldigt grundläggande saker ibland.
Då funderar jag mycket på, och så fastnar jag lite i det där för att jag vill på något sätt inte
fula nedkåren. Jag vill inte vara mindre smart.
Men då kommer jag alltid tillbaka till att min grundläggande tanke kring att vara konsult är
ett, vad kan jag skapa för värde?
Två, jag vill bygga någonting som fungerar och som skapar det värdet.
Och sen, jag ska lämna efter mig någonting som någon annan ska ta hand om efteråt.
Och jag vill att det ska gå att ta hand om det efteråt.
Ja, det var jag verkligen.
Ja, för det var ju verkligen så här...
Om man jämför med hur jag var för tre år sedan kanske, eller något.
Bara på ett annat exempel.
Jag var väldigt nöjd när jag lyckades vara klyftig i koden.
Alltså när man gjorde någonting, "Fan, herrejävlar vad klyftig jag var!"
Och så kommer man tillbaka liksom två dagar senare.
Det var ingen tid som var betaget, man bara "Vad fan har jag gjort?"
Och ingen kunde läsa vad koden gjorde liksom längre.
För två dagar sen var det jävligt smart.
Det är det värsta. Det hatar jag nu.
Jag kan fortfarande komma på de här klyftiga lösningarna.
Men då är det snarare åt andra hållet att jag börjar med den klyftiga lösningen.
Och sen refaktorerar man det till att det blir läsbart.
Istället för förr kanske man skrev mycket mer kod från början.
Så refaktorerade man det ner till så få kodråd som möjligt.
Så där sitter jag mycket också.
Ibland är jag också så här.
"Titta, titta, Therese kan också tänka!"
Och sen bara, "Ja, men det här är inte nice, det funkar inte som det ska."
Då får man gå tillbaka till det här, får det bara att funka och sen gör resten.
Sen, har du ens problem, framtida problem?
Alltså, det här med att vi hade en grej där vi satt upp ett storybookprojekt
för att börja dra in en massa komponenter.
Och så började vi bygga komponenterna i Storybook först.
Och Storybook är bara för en bibliotek med komponenter?
Ja, man behöver inte använda Storybook. Storybook är bara för att visa upp dem i en grej.
Men ett React-komponent, bibliotek för återanvändbara komponenter, ofta för styling och såna grejer.
Mycket knappar och sådär.
Och det tycker jag är skitbra, speciellt om man har en styleguide eller någonting.
väldigt bra för små komponenter. Knappar, checkboxar, input-rutor, allting som återanvänds hela tiden.
Och så kan du sätta dina färger på olika klasser. Det är skitbra, men när vi började,
allting skulle byggas i Storybook, eller i det här komponentbiblioteket.
Är det en komponent, då kan vi bygga det här i, och sen så kan vi dra in det i projektet,
och så kan vi försöka tweaka det och se om det passar alla våra use cases.
Vi har byggt en komponent som enbart ska finnas på ett ställe.
Vi har lagt till 500 olika "what ifs" och eventualiteter för att eventuellt kunna täcka ett case för när den här komponenten vill användas på ett annat ställe.
Men det har inte hänt och koden är inte läsbar.
Ja. Oklart om man har lyckats då eller inte.
Jag har suttit med det här hobbyprojektet och har varit flera gånger när jag nästan har börjat optimera saker också.
Det är också lite samma tankegrej. Det är ingen som har använt det här förut.
Jag har inte ens testat hur performance är.
Om jag skulle göra så här istället, då skulle det förmodligen gå mycket snabbare.
Sen började jag skriva det och sen kom jag på det.
Varför gör jag det här nu? Projektet är inte klart.
Det saknas massa features, men jag kan ändå optimera performance.
Får det bara funka?
Exakt. Nu har jag verkligen gått ifrån det.
Jag har ganska mycket lite ful hack i det just nu.
Som inte är jättesvåra att bygga bort.
Men jag kanske vill ha config i environment-variabler istället.
Nu är de hårdkodade bara, som variabler.
För det var också på väg. "Fan, jag ska lägga in en config-service här så man kan hämta config från."
"Vad fan ska jag göra där för?"
Helt jävla värdelöst.
Det är liksom bara jag som kommer hosta projektet.
Bara jag som kommer ha det.
Så jag har hårdcoded in allt.
Och det är där det är just nu.
- Ja, jag tryckte in alla nycklar och pushade upp dem.
- Ja, exakt. Det är ett privat gitarre på det än så länge.
Så än så länge är det lugnt.
En annan grej som fick mig att välja TypeScript på just det här projektet var att jag ville köra ett nytt state-hanteringsbibliotek
som heter Overmind. Alla tycker att det säger "Ubermind" när jag säger det här, vilket inte alls är det jag säger.
Men jag har alltid varit lite anti-Redux. Gillar du Redux?
Det har gått lite upp och ner. I början var det fascinerande, vad är Redex?
Varför använder man det? Oj vad skönt, vad häftigt.
Sen blev det så här, fan så här grötigt det är.
Och om man inte använder det på rätt sätt så blir det problem.
Det är grötigt och det är tungt och ibland kanske inte ens nödvändigt att ha.
Men jag är lite så här...
- Mm, jag fattar.
Det känns som att det här skulle vara ett kontroversiellt ämne.
Det här är avsnittet kontroversiellt ämne, Redux.
[Skratt]
Jag är väl också så här,
Redux är väl ganska nice och det har blivit mycket bättre, tycker jag, på senare tid.
För nu finns det ju massa grejer som tar bort all boilerplate och gör att man kan skriva ganska snygg Redux-kod.
Vilket jag inte tyckte det var så enkelt att göra förut.
Men man bygger ju massa grejer som jag tycker blir överkomplicerade.
Det finns en Redux-saga, körde vi på ett projekt jag satte förut.
Skitsvårt att följa med vad som händer, men det är så här generator, så fan fett allt.
Och då känner man att "Åh, här vill jag inte vara".
Nej, det har jag mest hört om. Man ska bygga en saga om allting som ska ske på vägen.
Det projekt jag tyckte var det roligaste jobbet med Redux i var när vi drog in selektorer.
Alltså inte ens komplicerade, utan bara getters.
Då fick jag ut data på ett väldigt trevligt sätt och kunde välja komplicerade saker och nuddecheckar och sånt kunde ske i selektorerna.
Det var jäkligt trevligt.
Ja, det kan jag tänka mig.
Jag har inte kört överdrivet mycket vid Axeller, men det har aldrig riktigt klickat för mig.
Jag förstår ju hela konceptet med reducers och allt sånt, men det känns som att det är väldigt sällan man behöver allt det.
Ja, men sen blev det också, det blev någon konstig grej, för jag kom liksom från flux och flexible satt jag i innan.
Och det var så här, ja det var det som kom först liksom, det var ju byggt på, ja men det som Redux bygger på också egentligen,
att det är Facebooks den här, så här tänker vi att man ska hantera statet, det är så här unidirectional flow, absolut.
Men då blev det nog lite så här, här sitter jag i Flexible, som ingen vet vad det är.
Och sen när man fick komma över till Redux då, det var så här, aaaah, nu snackar vi.
Ja det är lite kul, för projektet jag börjar nu kommer vi köra Flexible, eller de kör Flexible i ett projekt.
Så det kanske vi kan snacka om i ett avsnitt ni har, satt mig in lite i det. Det känns supermodernt och hett.
Nej, men det jag vill komma till egentligen är att jag tycker att "overmind" är så jävla nice.
Du tycker väl att du säger "overmind"?
Ja, jag vet att det låter som att man säger "overmind", men jag har ju tydligen sämst uttal.
"Overmind".
"Overmind", det är norrländska.
Det är norrländska, alltså. Sipprar fram där. Det kommer vi få ha som möjlighet.
Jag tycker känslan för mig har lite samma som när jag körde Vue förut.
För de har ju sitt state hanterings som heter VueX, som är det officiella liksom.
Och det tyckte jag var oerhört straightforward, det var liksom inga konstigheter.
Det var bara att använda och så fattade man det direkt.
Och samma känsla har jag då med Overmind.
Och för att förklara lite kort, för du har ingen koll på det.
Nej.
För att förklara, man har state.
Och state är bara ett objekt som är state-trädet.
Det är hela statet.
Sen kan man dela upp det på vilket sätt man vill.
Men staten är ett objekt.
Sen har du actions för att mutera state.
Här går man från Redux till exempel att man muterar inte state utan man reducerar.
Men här är det så att du har en action.
Det är den som gör att den får in sitt state och så eventuellt nåt.
En action är en metod i stort sett.
I den metoden kan du mutera state-trädet hur mycket du vill.
Det är typ det.
Sen finns det en hook till exempel för att "use overmind".
Då kommer komponenten att tracka om den använder något state från overmind.
Man kan även få ut sina actions och state-trädet.
Och så kan man bara anropa de här metoderna.
Och allt bara funkar.
- Men är det samma sak då, att du har ett state,
och oavsett var du uppdaterar i det så uppdateras hela statet?
Så alla som drar in statet kommer att uppdatera sig?
- Nej, bara de som lyssnar på den specifika grejen som ändras.
- Okej, så det är inte att hela statet... - Nej.
För det är ju liksom så här, att den...
Jag vet inte, det finns något som heter Proxys i javaskript,
modern javaskript nu för tiden,
Man kan lyssna på förändringar på objekt och grejer och variabler.
Och jag tror att det är det som det här bygger på.
Som gör att det här är möjligt.
Jag tror att Vuex gör samma sak under huvudet.
Jag är inte helt 100, men...
Vuex är det i streams och grejer?
Nej, det är väl också något i stil med det här.
Att du har ett state. Det var ganska länge sedan jag körde Vue, så jag har inte stenkoll längre.
Men då får man ju också in sitt globala state.
Då har du en store som du har ditt state på.
Och på den storen kan man köra mutations och nånting mer.
Och mutations är något som ändrar och grejer.
Jag har bara klumpat ihop allting med x till streams, observable pattern, rx, vx.
Allting med x och min hjärna bara "det är det där" som jag inte har koll på.
Jag tror inte det är Observer och CVOX. Nu vågar jag inte säga det helt.
Det är grunden i hela state-hanteringen.
Det är bara det man behöver för att sätta upp det.
Sen funkar det skitbra med TypeScript.
Du får ju allting typat. Allt du skickar in är typat.
Allt du får ut är typat.
Och det är lite byggt för att man ska köra med TypeScript i stort sett.
Vet du vad Code Sandbox är?
- Vad är det? - En hemsida som heter det.
- Internet. - Ja, exakt.
- Det där offline-grejen. - Du kan också skicka över kod via Code Sandbox.
Ja, exakt. Code Sandbox är typ Visual Studio Code i webbläsaren.
De bygger på samma underliggande open source-grej.
Men sen har de en massa mer grejer. Du kan sätta in npm-paket och saker i webblösan.
Det är typ som CodePen är också ett variant på det där.
Fast de kör bara åt mlcc, JavaScript och React.
Jag försökte verkligen komma på vad det är som jag tänker på, men jag kom inte på vad det heter.
Det känns som att det har... är det JsFiddle jag tänker på?
Det kan det vara. JsFiddle finns också.
Där man kan köra JavaScript i browsern.
Och Code Sandbox är väl en lite mer...
Det är ju typ en IDE för webbutveckling i browsern i stort sett.
Och de kör nämligen Overmind för hela sitt state.
Så därför följer jag några av dem på Twitter som jobbar där.
Det var ändå en lång förklaring att komma fram till något för att kunna name droppa ett ställe.
Nej, men jag tänker att folk känner till Code Sandbox.
Ja, jag vet.
Ja, i alla fall.
Och det funkar bra.
Sen har de också ett koncept som heter "Effekts"
som är tänkt som egentligen abstraktioner för allting som är sidoeffekter.
Så typ API-an upp, om du vill hantera local storage.
Jag kör socket-grejer.
Så för alla de här grejerna så gör jag liksom, man gör en grupp med effekter.
Och då kan det vara så här att jag har en grupp med effekter som är alla API-genrop.
Och det som händer då, som jag tycker också är en jävligt bra idé, är att då får jag ett API som ett interface
snarare i min applikation om jag vill byta ut hur jag gör API-genropen.
Så då skulle jag kunna säga att jag bara byter ut den här effekten som är API-anropseffekten
Så länge den har samma input/output-data, då kan jag byta ut hela API-anropsgrejen
De har många exempel där det visar sig att vi gör en effekt för API-anrop
och sen skickar vi in i den vilket bibliotek vi vill använda för att göra anropen
Typ Axios eller Request eller vad man nu kan köra
Och det tycker jag är en jävligt bra idé.
Bygger du egna effekt som du sen kan köra i en egen ljuseffekt som körs som ljuseffekt?
Ja, det är mycket så här att saker heter samma sak.
För de här har ju liksom ingenting med ljuseffekt att göra egentligen.
Men så kan man liksom lägga allt in där.
Så jag har till exempel alla mina socket-grejer.
De är liksom uppsatta som en effekt, som webbsocket-grejer.
Och det enda jag gör där är att jag skickar in till den.
Man kan säga att när vi initialiserar den här effektgruppen, då gör vi det här.
Så då skickar jag in att det här är de event som jag vill lyssna på och det ska trigga de här actionsen.
Så då knyter jag ihop mina effekter med mina actions och på så sätt har de ingen vetskap om varann egentligen.
Så om jag vill byta ut och gör så är det socket.io nu till exempel för att köra socket-grejerna.
Så om vi vill byta ut den så är det typ, byta ut en fil så är det klart.
Nu kommer det aldrig att hända.
Det här är så jävla bra egentligen, att vi pratade om abstraktioner som man gör i onödan.
För det här är exakt det där.
Det fanns ingen anledning att jag skulle behöva göra det här egentligen,
förutom då att testa biblioteket.
– Ja, för jag undrar också den här grejen att man, statehantering är ju idag.
Då, vart går gränsen? När känner man att man vill dra in en statehanterare?
Jag håller med. Jag har också, många andra projekt har jag kört på senare tid,
att man kör bara props som man skickar ner.
Har man states man vill skicka i sidled så kör man just context.
Och så har man en context med sitt state som man skickar i sidled.
Eller att man sätter ett litet globalt state på en context och så skickar man den fram och tillbaka.
Och då är det väldigt sällan man behöver det.
Nu tycker jag att deras approach, eller deras idé bakom tror jag är att
de vill att man ska ha, eller deras åsikt är att man ska ha statehanteringen på ett ställe för att det är nice.
Alltså det är skönt. Då slipper de hantera sig på flera ställen.
Men sen är det ju precis som du säger, att det är svårt att avgöra när ska man ha det globalt,
när ska man ha det i komponenten.
Ibland kan de flytta ihop ganska mycket.
Ja, men att ha en state hanterar överhuvudtaget är lite så här,
var, när, tycker man att det är dags, alltså jag kan verkligen tänka mig
de här side effects grejerna om man kan dra ihop dem på ett eget sätt.
Det kan jag tänka är jäkligt trevligt.
Och å andra sidan kan jag också tycka att man kan bygga en egen
use-effekt eller en egen hook i React och samla allting där.
Det skulle kunna bli samma sak.
Ja, definitivt. Med hooksen nu så är det skitenkelt att bygga delad logik.
Så man skulle kunna ha en hook som gör allt det här åt en.
Ja, så kan man bygga en Uberhook och så kan man se till alla eventuella framtida problem
och så kan någon ta höjd för det.
Exakt.
Ja, det är perfekt.
Jag tycker i alla fall att det är väldigt trevligt.
Mycket för att man får ett state-träd som alla lyssnar på.
Sen är det klart att man har ju lite lokalt state i komponenten också såklart.
Men det har gått väldigt fort att bygga med det.
Vilket har varit väldigt härligt.
Det finns lite mer avancerade grejer som jag inte har testat.
De har något som heter Operators.
Som är typ att...
Det är lite mer funktionellt, tänk.
Det vill säga att istället för att, om jag sa en action nu då, då är det tänkt en metod rakt upp och ner.
Och den metoden gör massa imperativ logik som säger att om det här händer så sparar det här statet, eller om det ser ut så här så sparar det här statet och så vidare.
Operator säger lite mer åt funktionellt håll att du kör en pipe-funktion och sen skickar du in massa funktioner i den
som körs i ordning för att mutera statet.
Och då finns det ju en "mutate"-funktion för att mutera statet.
Och det var, ja, du fattar.
Och visst, det ser ganska trevligt ut, men det kände jag var helt oerhört kul.
Jag kommer säkert att testa det sen för att se hur det känns, för att jag tycker biblioteket är överhuvudtaget så jävla bra.
Sen har de också något som de kallar för state charts.
Det är väl en stor idé, det är som en state-maskin.
Det vill säga att man definierar vilka states man har i applikationen, och sen definierar du vilka states som kan gå till vilka andra states.
Det vill säga om du har statet login, då kanske du kan gå till statet logged in och till statet failed login, till exempel.
Och det Overmind gör är att man kan spesa vilka actions kan köras i vilka states, till exempel.
Vilket gör att om du säger att, det lägger ett lager ovanpå med logik som säger att
"Okej, men om vi är i login-statet, då kan vi inte köra logout-actionen, till exempel."
Och den tror jag skulle kunna vara ganska vettig för det jag bygger, för att jag har ganska många olika states.
Alltså, det funkar så att man skapar ett rum och då väntar man på att spelare ska komma in.
Sen när spelare kommer in så kommer det vara en countdown som är på 10 sekunder.
Och det är ett state, och under den tiden så kan fler spelare "joina".
Och så vidare.
Så där känns det ganska vettigt att det kan spesa.
Vilka states kan applikationen vara är mer konkret än att det bara lever i en state-variabel.
Ja, det låter helt klart vettigt. Men det är intressant ändå när du säger det här, att det har gått fort att bli gay.
Om du upplever att du har dragit in statehanterare i andra hobbyprojekt, det är svårt att mäta nu också, men du kanske har en annan kunskapsnivå och erfarenhet.
Men känner du verkligen att det här har verkligen varit skillnad i hastighet och sätta sig in i och förstå jämfört med andra?
Eller är det mer så här, ja men det gick fort. Jag är ett projekt som inte har skalat upp stort än och som kanske inte har stött på alla problem än.
Nej men, ja, precis, det är svårt att jämföra.
Men jag tror att det är den bästa startsträckan jag haft, tror jag, i ett state-hanteringsbibliotek.
Alltså kanske VUEx som jag jämförde med innan, att det var likadant.
Jag tycker dokumentationen är också väldigt bra, vilket hjälper väldigt mycket.
Halleluja.
Exakt, exakt den känslan där.
Men den energinivån också.
Exakt.
Jo, jag tycker nog att det har gått snabbare, men sen tycker jag också att
till exempel tittar man på den förra versionen av det här HB-projektet
där byggde jag bara min egen state-hantering med
typ kontext och use-reducer i
Hux och hade liksom en custom-Hux bara
och där blev det liksom mycket rörigare. Nu kan det ju såklart
vara för att jag vet, alltså har man byggt projektet en gång så lär man sig oerhört mycket
Det är nästa gång man bygger det.
Om hur man ska strukturera och sånt där.
Men jag tycker ändå att det har fått oerhört mycket hjälp.
Alltså så här, det är lättare att strukturera det i Overbind än vad det var i
i liksom UseReducer och UseContext.
Så att, ja, jag vet inte.
Jag tycker att det, jag kan fan inte rekommendera att testa det.
För att jag tycker att det är ruskigt, ruskigt bra.
Och jag vet inte, jag tror ju att man vill kanske använda det med TypeScript.
Om man gör det.
För jag vet inte om jag skulle...
Det kan ju vara kombinationen också.
Att jag får mycket hjälp av typescript som gör det enklare och strukturerat.
Jag får inte så mycket problem med att jag har skrivit fel och grejer.
Plus att det här hjälper till med allting.
Så jag vet inte.
Men jag tycker ändå att det är sjukt nice faktiskt.
Men det känns ju verkligen som att det hjälper dig att tänka.
Ja, det hjälper jag kan behöva ibland.
Ja, men mycket är den här att det inte bara är att använda de här prylarna så blir det bra.
Utan det är mer så här, okej, hur vill du faktiskt hantera, hur vill du att saker flödar?
Jag tror den där state chart-grejen låter ju ganska mycket så att man verkligen måste tänka till,
okej, vilka state går till vilka state? Vilka kan jag hantera här borta?
Att faktiskt bygga en chart av det.
Det är en lite kul grej här som jag tycker är...
Det är både positivt och negativt, men de har ju DevTools som alla andra state-hanteringsbibliotek nu i tiden.
Men det som är irriterande är att det finns bara som en extension till VS Code.
Eller att man kör en fristående på datorn.
Det är liksom ett npm-paket som du kör bara npx och sen... ja, vad det nu heter, Overmind, DevTools kanske.
Problemet är att den bara ansluter till ett fönster åt gången.
Vilket är skitjobbigt när jag bygger en multiplayer-grej.
Så det senaste fönstret jag refreshar är den som den kopplar staten på.
Och det är ju oerhört irriterande.
Sen tycker jag den är rätt bra, för man ser exakt vilka actions har körts.
Du kan se exakt hur statet är, du kan gå tillbaka och time-travela och grejer.
Och om man körde state charts såg jag att då får man även ut en visuell bild.
Så här ser din state chart ut som ett diagram.
Och vilket är vi nu, hur gick vi dit och så vidare.
- Det är riktigt nice.
- Ja, så när jag har bytt klart det så kommer jag nog refakturera till state charts.
För att slippa... Jag ska inte göra någonting i förväg.
[Skratt]
Utan vi ska få ut det så att folk kan köra det.
Det är också ett projekt jag vill få ut nu när folk är hemma och kör remote-avis och grejer.
Men hur är det? Alltså dokumentationen är bra, sa du?
Ja, jag tycker den är bra.
Tack och lol. Jag hatar när man inte förstår dokumentationen.
Men community då? Om du stöter på problem, kommer det vara? Det är ändå ganska tyst än så länge.
Ja, jag tror inte att det är en superstor community.
De verkar vara ganska aktiva och hjälpa till om man twittrar saker eller skriver på en issue på deras skithub.
Men ska jag vara helt ärlig så har jag inte haft ett enda problem.
Jag har väl haft någon gång när jag kollat upp dokumentationen såklart.
Men jag har aldrig haft någonting som jag bara har fastnat i.
Det känns som att det är såpass straightforward att det inte händer.
Sen gör jag ju inte de komplicerade grejerna som operators eller state charts.
Men överlag så tycker jag att det funkar väldigt bra.
Men Anton är lite frälst ändå av "overmind".
Exakt. Nej men alltså Gud ja, det är jag definitivt.
Och så här, jag skulle vilja prata med någon som har kört det i någon större projekt och se vad de spar in för problem.
För någonting måste det finnas.
Nu får väl fråga Codesandbox-folket.
Ja, jag får väl göra det. Men han som har gjort det där jobbar ju på Codesandbox.
Så att jag tänker att det finns för säkert något problem de har.
Du får hitta honom om en bloggpost eller någonting.
Ja, det kanske man ska göra. Vi får se.
Men ja, vi får se. Jag kan försöka återkomma till det här när jag har byggt art och gjort lite stage arts och grejer.
Det känns väl ganska vettigt.
Ja, tänk om det här blir nya stora heta.
Då sitter alla här om ett år och kör Overmind.
Exakt, då kan jag vara en expert.
Det finns ju uppmål att inte vara expert på längre, i och med att jag har sagt det enkelt här.
Om det inte blir så att alla verkligen byter ut och kör GraphQL och Apollo.
Ja, det måste vi också prata om i något avsnitt, för jag kan ingenting om GraphQL.
Jag vill kunna GraphQL, och du kan ju GraphQL.
Vi ska ju inte ta i här.
När du säger att vi ska inte ta i så betyder det ändå ja, för du trycker ner dig själv lite varje gång.
Det betyder kanske att jag har jobbat med det, men jag har inte jobbat länge med det.
- Nej. - Eller djupt med det.
- Kan ju mer än mig.
- Om du kan ingenting, så är ju fräskeln inte så hög, tänker jag.
- Det är också väldigt sant.
Jag tror att jag har pratat jättemycket, jättelångt och jättesnabbt nu om Overmind.
Så jag tänker att folk kanske är lite trötta på att höra min röst.
- Norrländskan. - Norrländskan.
Overmind.
- Ska vi säga så för den här gången? - Ja.
- Eller har du något du vill tillägga? - Nej, det har jag inget.
Vill man nå oss så finns vi på Twitter. Jag heter @AvnetonW, du heter?
- @teekomstadius. - @teekomstadius, länkarna finns i beskrivningen.
Vi skulle också kunna passa på att tacka mina vänner som jag helt
Brutalt utnyttjat. Först skulle jag vilja tacka Therese Nilsson för att hon gjorde vår cover-bild, eller vad heter det?
- Ja, vår logga. Den ni ser i alla fall. - Och sen så har vi även fått ett outro som ligger som ett ljudspår.
Och det har fått Pär Strandberg. Så tack mina kära vänner!
- Du har utnyttjat dem mycket.
Vi hann ju faktiskt sminka in outroet på förra avsnittet redan.
Så det låg redan där.
Och det kommer.
Hejdå!
