59. Man ska inte prata skit om kod men here we go
lyssna! 
Efter att ha avverkat Therése framtida standupkarriär gräver vi ner oss i React-hookarna useCallback och useMemo. Vad är de för något, varför finns de och hur ska de användas. Dessutom en hel del om closures, tunga uträkningar, ordo, automatisk memoisering, Reacts nya hook och mycket mycket mer.
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:
How do trees use the internet?
They log in.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) How do trees use the internet?
Jag vet inte.
They log in.
Det var gul. Jag trodde det skulle komma något med fiber ett tag.
Men den där har nog snott från internet.
Ja, men det är så att vi inte kan förvänta oss att vi ska hitta på 55 skämt till faktiskt.
De får du spolar till din stand-up-karriär inom tech.
Ja, otroligt smalt och nischat.
Gud vad kul att bara gå upp och ställa sig på en stand-up-scen och köra bara de här skämten.
Det är också kul att jag fastnade någonstans i mitt huvud.
Det är de dagarna man borde ha stand-up och prata om de här blåa tossorna man måste ha på sig på läkarmottagningen när det är blött ute.
Hur fruktansvärt jobbigt det är.
Ungdomstrauma.
Hur som helst.
Hej och välkomna till ASDF.
Avsnitt någonting.
-58 kanske.
-Kanske.
Sa du inte att det var 59 förra gången?
-Jag vet inte, men vi är där någonstans i alla fall.
Snart pensionär.
-Snart pensionär. Det måste vi nog fira tror jag.
-Absolut, det löser vi på något sätt.
Det blir livepodd.
[Skratt]
- Ja, okej. - Det vill säga att du och jag poddade i samma rum igen.
- Det var ett tag sedan. - Ja, det kan vi väl se här.
- Dricka en cocktail. - Exakt.
Nu ska jag sluta deraila det här avsnittet.
Ja, det är mitt jobb oftast.
Men idag har jag funderat på en sak.
Och det är att...
Åh, man ska inte snacka skit om kål.
Det jag sitter i nu, i en React-app, och nu kommer det bli i React så ledsen alla som inte är intresserade av det, men det är otroligt många ljusmemo och ljuscallback i den appen.
Jag har funderat så himla mycket på det här. Jag har läst en hel del och åsikter om man bör använda det överallt eller inte.
Jag känner att jag inte riktigt får någon rätsida på det.
Jag har väldigt svårt att se när det är bra och inte bra att använda det.
Så jag tänkte höra lite dina tankar kring det här.
Just det.
Jag älskar ändå att man inte ska prata skit om kod, men "here we go".
[Skratt]
Man ska inte prata skit om andras kod.
Nej, absolut.
Och vi kan låtsas att det här är koden som du har skrivit, fast du är förvirrad över varför den är skriven som det är.
Precis. Så här, caset är
jag har hört att ljusmemo och ljuskålback ska användas för prestandaoptimering,
så nu har jag lagt in det precis överallt utan eftertanke och nu funderar jag på om jag har gjort rätt.
Jag skulle ju spontant säga att du inte har gjort rätt.
–men det beror ju lite på hur resten av koden ser ut.
Om vi börjar med "use memo" kanske, som är ett av världens mest svåra ord att säga på svengelska.
"Memoise".
–Memoisering. –Ja, memoisering. Toppen.
Det går ut på att du ska ta nånting som gör en uträkning egentligen.
och se till att den uträkningen bara görs när den behöver göras.
Så om du har en funktion som gör någon komplicerad och tung uträkning
så kan man stoppa in den i en ljus memo och så säger du att "kör bara den här uträkningen när den här variabeln ändras".
– Ja, för hela poängen med en funktion är att den ska ge exakt samma värde för exakt samma input varenda gång du kör den.
Ja, precis. Så att du vill inte stoppa in en funktion där i som beror på tid, till exempel.
Det är spontant ganska dåligt.
Ja.
Och det är poängen med den.
Och sen useCallback är ju egentligen samma sak, bara att den ger i React-världen en stabil referens till en funktion.
Så att när du deklarerar en funktion i en komponent i React,
om du bara gör det rakt upp och ner i komponenten,
så kommer den funktionen skapas om varje gång komponenten renderas.
Så varje gång komponenten renderas så får du en ny referens till den här funktionen.
Just Callback är på samma sätt som man skickar in den här funktionen, eller "wrappar" den i Just Callback
och skickar in vilka beroenden den har.
Då kommer du bara få en ny referens till funktionen när beroendena ändras.
Och här glider vi också lite in på closures i JavaScript.
Men vi kanske kan undvika att prata om det här för det är lite jobbigt.
Jag är helt blank. Jag vet ju vad det är men jag vet inte vad det är just nu.
Closures är ju när funktioner i JavaScript kan använda data som är definierade eller deklarerade utanför dem.
Och att de då "closes" över den datan.
Så att när funktionen kör så kommer den ha en referens till den datan som den var när funktionen skapades.
Vilket gör att du kan få, om du gör en funktion som "console.loggar" ett värde som du har definierat utanför funktionen.
Och sen ändrar du variabeln på det värdet utanför funktionen så kommer fortfarande funktionen konsologga det gamla värdet.
Om det har blivit ett closure.
Det är väl typ ett problem man brukar springa på.
Men closures är meckiga och det finns edge cases och massa grejer med dem.
Man behöver inte riktigt veta vad det är för att vi ska förstå just Memo och just Callback tror jag.
Nej, en sak som är bra att veta är att både ljusmemo och ljuscallback har en dependency array som säger att titta på de här värdena och när de ändras är det då du vill göra nya beräkningar.
Om jag förstått det korrekt, till skillnad från ljuseffekt, som också har en dependencyarray som säger "kör den här effekten när de här beroendena förändras".
Men ljusmemo och ljuscallback som jag förstått det, de fattar faktiskt att det inte är en ny referens till objekt, utan de facto nya värden i objekten.
Men det gör inte ljuseffekt, ljuseffekt går på nya referenser.
Det kan säkert stämma, jag har faktiskt ingen aning.
Jag tyckte mig läsa det nyligen.
En anledning till att jag inte vet är för att jag använder inte UseMemo eller UseCallback så ofta.
Nej precis, jag har ju historiskt sett inte gjort det heller.
Det är som att jag inte har kodat React med React Hooks tidigare, men det har jag nog.
Men jag har använt det väldigt väldigt sällan och därför blev jag så himla
överraskad över att det var
Allt var ljusmemo och ljuskålbär. De är inte små.
De är ju 100-200 rader långa.
Ja, alltså de användningsområdena som jag har använt till dig då,
om vi pratar ljusmemo först, då är det ju till att just
begränsa att tunga uträkningar körs på varje rendering.
Annars, om det inte är en tung uträkning så tycker inte jag det finns någon idé
att slänga in den i en ljus memo förrän man får performanceproblem.
– Nej. För det är det också de säger överallt, liksom.
Att så här, ja, absolut, prestanda. Men prestanda har sitt pris.
För att hela poängen med det här är att det kostar minne.
För att, jag menar, okej om du har en jättekomplex uträkning i en ljus memo,
men om du har typ, dependar på fem variabler,
Då kommer det att kosta en massa minne för att den ska hålla reda på de olika states för de här.
Så jag vet inte om du vinner på det i slutändan ändå.
Nej, precis. Det ska ju till att det ändå är något ganska pressant och krävande för att jag ska wrappa den i en just memo.
För jag tycker inte att att wrappa allting i just memo, det kanske känns bättre om man inte tänker på vad den faktiskt gör.
Då begränsar vi antal renderingar på den här komponenten.
Men i verkligheten är det som du säger, att det kommer med en kostnad att använda en funktion till.
Och den är ju oftare mer prestandakrävande än vad det blir att räkna ut siffran från de här tre variablerna några gånger.
Ja, men vad snackar vi som tunga uträkningar? För det är ganska många som har så här, ja det är stora switchar.
Men de är inte så jäkla, jag vill slänga in Ordo här.
Ja exakt, nu förlåter Ordo och, eller vad heter det på engelska, Big O heter det väl.
Då är det en throwback till universitetstiden, absolut.
Algoritmer och datafrikturer.
100% har inte använt Ordo i jobbet en enda gång.
Nej, vi kan länka Ordo i beskrivningen och sen kan vi gå vidare.
Men det är väl egentligen ett sätt att beskriva hur prestanda är krävande.
Eller hur många gånger någonting måste köras för att göra uträkningar baserat på dess input.
Ja, det är mycket så här.
Om man ska ta in det, att göra platta saker kostar inte så jävla mycket.
För platta saker så menar jag ju, alltså typ som if-satser är ju platta.
Switchar är ju också platta.
Det är liksom en check på värde du får in och sen har du ett resultat från det.
Om du inte gör en massa komplicerade uträkningar i dem då såklart.
Men att göra själva checken kostar ju inte så mycket egentligen.
Det är mer så här, börjar du lopa och göra recursiva anrop och så, då kan du ju få en exponentiell ökning i vad det kostar att köra de här och så vidare.
Ja, exakt. Har man en loop i en loop, då kommer den ju ofta öka exponentiellt.
Ja.
Det är precis ett sätt att göra det på som aldrig har fått användning för efter universitetet.
Men jag vet inte riktigt vad man ska definiera som tunga uträkningar.
Jag tror att det handlar mer om, för mig handlar det om att när jag märker att prestandan påverkas.
Man kan göra väldigt tunga uträkningar för att transformera massa data för att du vill rendera det på ett annat sätt än vad datan är strukturerad.
Och strukturerar om den och då blir det lite loopar i loopar eller att du kör Map och Reduce eller Filter och allting sånt.
Oftast så behövs det inte ens det att göra. Men är det väldigt mycket data, då kanske man ska sträcka sig efter JustMemo.
Men då blir det istället så här...
Då kanske lösningen egentligen är att virtualisera en lista till exempel.
Istället för att vi ska rendera all den här datan, då kanske vi bara kan ta ett subsätt av den datan och rendera samtidigt.
Och så har vi virtualiserade listor som renderas när man scrollar till exempel.
Så ofta finns det andra lösningar än att man ska "wrappa" de ljus mem och hoppas att det funkar i längden.
Jag tänker om du ska sortera en massa och sånt också, men det vill man väl också göra.
Virtualisera, vad säger du egentligen?
Det heter virtualisera tror jag.
Det finns en bibliotek som heter React Virtualized.
Som är ett tabellbibliotek som är byggt specifikt för att du inte ska rendera hela tabellen utan att det renderas de tio raderna du ser.
Är det någon typ av paginering eller "lazy loading"?
Ja, typ "lazy loading", fast du kastar också bort där du scrollar ut ur bild.
Jaha, "today I learned".
Ja, det är ett väldigt bra uttäckte. Det finns väldigt många bra bibliotek för det.
För det är lite mäckigt att implementera själv.
Men om man har väldigt mycket data så är det väldigt vettigt att virtualisera sina taveller.
för att slippa rendera allting samtidigt.
Så renderar du bara det som du vill visa upp samtidigt.
Det är någon som har så jävla bra koll på Ordo som har byggt om där.
Ja, det är det garanterat.
Jävlar i havet.
Det tycker jag är ett bra tips.
Att sträcka in det efter just memo först, för den kanske stoppar problemet just nu.
Men sen blir det mer data ändå så kommer inte heller det funka.
Eller om datan börjar ändras oftare, eller vad det nu kan vara.
Nej, alltså jag menar det där känns ju ganska vettigt såhär, att plocka in det när du känner att det finns behov.
För jag är ju fortfarande lite i chock av att folk hela tiden lägger saker vid ljusmemo för att jag är, men varför? Varför håller du på med det här?
Och den här barnen till exempel borde ju inte rendera om, ens om propparna inte ändras.
Jag förstår inte vad som händer, riktigt, vissa gånger.
Men det är ju inte så att jag bara rakt vågar gå in i en central chock i appen som har en hundra rader lång ljusmemo och bara yrka den.
Nej, det kan jag förstå faktiskt.
Jag tycker det är så svårt när det är så långa.
Att innehållet i Just Memo eller Just Callback blir så väldigt långt.
Då blir det ju helt plötsligt lite mäckigare att ändra det.
Det finns ju vissa fall när det kan vara värt det.
Som sagt, när det tar väldigt lång tid.
Eller som också är ljusgriset för Just Callback.
att du vill inte att det värdet eller den funktionen förändras för att du skickar den som en prop till en annan komponent, alltså en barnkomponent.
Du vill förhindra att säga att den barnkomponenten har det här värdet eller den proppen i en useEffect dependency array till exempel.
Då vill du inte att den ska köras om varje år i den här funktionen, eller varje gång föräldrar funktionen renderas till exempel.
Då kan det vara vettigt att använda useCallback eller useMem
beroende på vad man gör.
Men det är ett av få vettiga use-case som jag tycker att det finns.
Men vad är det då för vettiga use-case det handlar om?
Vi har en föräldrakomponent som definierar en
"handleChildUpdate" som är en funktion.
Och den funktionen tar emot någon typ av data och gör någonting med den.
Det spelar inte så stor roll vad.
Men den lever i föräldern.
Den skickas ner till barnkomponenten.
Den har en use-effekt som körs på grund av någonting.
Och då vill den köra den här proppen som skickas ner.
Alltså den här HandleChildUpdate-funktionen.
Ska man följa de här hookreglerna som finns.
ska ju även HandleChildUpdate-funktionen ligga med i barnets UseEffectDependencyArray.
Ja, det här är också någonting som vi bör diskutera.
Och om man då lägger med HandleChildUpdate, alltså den proppen, i dependencyarrayen.
Det som skulle hända då är att den useffekten skulle köras om varje gång
för att då har HandleChildUpdate-funktionen också förändrats.
Alltså det är en ny HandleChildUpdate varje gång det renderas.
Så skickar man den som en prop till barnet så kommer ljuseffekten köras om i barnet varje gång.
Då kan det vara vettigt att man "wrappar" HandleChildUpdate-funktionen i föräldern i en ljus callback.
Ja, det där makar känslan. Jag tänkte att det var någon mer specifik case, men det handlar mer om alla handlers så länge det är något som behöver hanteras i en side effect.
Ja, sen ska det ju sägas att jag har ju mer och mer, och mycket tack vare den nya React-dokumentationen, proppsat för att man inte ska använda use-effect.
Eller att man ska använda useeffect så lite som möjligt.
Och det finns en svinbra sida i den nya React-dokumentationen, den som ligger på beta.react.org
Som bara pratar om att du kanske behöver inte använda useeffect.
Och den är så jävla bra.
När den nya dokumentationen landar skarpt så kommer den att göra stor skillnad för hur folk skriver React.
Den pratar mycket om att man inte ska lägga saker i ljuseffekt som är på de här fem-sex olika fallen.
Det är väldigt vanliga fall.
Du ska inte använda ljuseffekt för att uppdatera state beroende på props.
Det är ett vanligt fall.
Du har något state som du vill använda när props ändras och då kör du en ljuseffekt.
Men det ska man inte göra.
–Vad ska man göra då? –Du kan göra det i rendermetoden istället.
Render ska bara köras när propsen ändras.
Sen beror det lite på vad man gör.
Men du kan också köra den till exempel om det bara ska ske en gång.
Då kan du stoppa in det som en initializer till useState.
Du kanske inte ens behöver ha en state-variabel.
Alltså en useState.
Du kanske bara kan ta propsen och sen konvertera dem och göra om det.
Det finns massor av alternativ på hur man kan lösa det.
Men jag tycker den är svinbra, så den kan jag rekommendera att läsa.
Vi länkar väl den också i beskrivningen.
- Alltså det här är lite intressant för att jag har ju känt mig helt i alla off.
Eller, helt off.
Med lite off i den här appen för att jag är så här,
okej, men det är ljusmemma överallt, det är ljuskålbark överallt,
det är ljuseffekt överallt,
det är ljuseffekt med dependency array som saknar alla typer av dependencies.
Det är också en eskildintregel som är avstängt för att man inte vill att den ska klaga på att man inte har mätt i dependency arrayen för att man hamnar i fel.
Kodar jag React fel?
För att jag är ju extremt sparsmakad med allt det här.
Jag bygger en komponent genom att göra en render.
Behöver jag det här så kollar jag hur jag får tag på det.
Jag gör ju inte funktioner i render. Jag lägger konstanter tills jag behöver göra nya uträkningar.
Jag försöker göra så lite trixiga saker som möjligt.
Ibland är jag väldigt rädd för att jag är så här.
Men är det för att jag är lite korkad?
Att jag inte fattar de här coola sakerna?
Eller varför måste det vara så komplext?
För jag tycker inte det behöver vara så komplext alltid.
Och då känner jag mig lite dum.
Jag tror definitivt att ditt sätt är mer rätt, om man ska säga så, än motsatsen.
Jag tror också att det har varit lite problem sen Hooks kom.
Det var väldigt mycket "vi måste förklara hur de här Hooksen funkar"
och se lite grann hur de ska användas.
Och även att React-teamet själva inte riktigt hade koll på vad som var best practices.
Jag tror det är lite målet med den här nya dokumentationen att skriva om den här
så att man kan lära sig en "Hooks first" approach i dokumentationen.
Vilket den nuvarande live-dokumentationen inte gör.
Och att man får lära sig hur man ska tänka i hooks och allting sånt mer än bara så här, det här är hooksen, här är hur den funkar, använd dem hur du vill.
Vilket jag skulle säga leder till att man så här, liksom spiller lite ljus memo och ljus callback här och där.
Ja, alltså jag hade ju, vi ska inte prata skit om andra skål. Jag ber om försikt.
Men det här är på svenska och de är inte svensktalande.
Jag hade lite pet-peeves när jag kom in i applikationen för det var ganska många ställen där de hade if-satser i början på komponenten.
Och liksom hooks under.
Och jag var så här, allting klagade på det och jag är det.
Om det finns en regel i React-hooks så är det ju att de ska användas unconditionally.
Så det var lite en grej, jag måste ändra på det här.
Det var lite "scary" att bara komma in i en ny app. Jag vet inte vad som hände, men bara rycka lite saker.
Och sen hade jag en annan grej.
Och det var att i ett antal ljuseffekter så gjordes Async-anrop i self-invoking functions.
Jag har inte sett en self-invoking JavaScript-function sen 2015.
–Typ. –Ja, just det.
Nej, och jag antar att det är gjort för att React skriker på dig om du gör async-grejer i en ljuseffekt.
–Ja, precis. Ljuseffekt-callbacken får ju inte vara async, så det du får göra är att skapa en funktion i asynken och sen så kalla på den.
Så det är samma sak, förutom att när du kör "prettier" får du ett semicolon framför self-invoking-funktionen som är...
...ohyggligt fult.
Men de hade ju också tagit bort "prettier", så att...
Det hade de. Men det var inte samma...
För det här var ju också... Det är ju lite både och.
Det är ju typ en byrå som man byggt och sen...
Ja.
Absolut.
Nej, men det är exakt.
Och jag tror att det är väl nånting React-världen lider lite av.
Särskilt när det kommer in nya React och folk ska förklara Hux och alla Hux förklaras som att de är som livscykelmetoderna i gamla React.
Det inte riktigt stämmer gör att koden kanske inte blir toppen jämt.
Nej.
Det är kul, en sak som jag tänkte på som var från React Conf 2021 tror jag.
Om jag minns rätt.
Så var det en presentation som var av någon...
Jag kommer inte ihåg vem det var som höll den nu.
Men det är strunt samma.
Den hette i alla fall React Without Memo.
Om jag minns rätt.
Det som presenterades där var ett litet experiment som de håller på med i React-teamet.
Där de har gjort typ en compiler som lägger på useEffect och useMemo och useCallback på alla ställen där det behövs utan att du behöver göra det själv.
- Jasså, jasså. - Och de kallar det för React Forget, tror jag, om jag minns rätt.
Alltså projektet. Bara för att det var liksom så här "Nu kan du glömma att göra det, för vi gör det åt dig".
Det var väldigt spännande. Presentationen i sig var extremt bra. Kanske den konferensens absolut bästa presentation skulle jag säga.
Så den är väl värd att titta på om man vill. Men det är det som de presenterade i alla fall.
Vi håller på att arbeta på att vi ska kunna göra de här optimeringarna, eller många av dem, automatiskt.
Ja, det vore ganska skönt att kunna släppa det.
Men på tal om det, var det inte så att de håller på med att skapa en ny hook som skapar upp handlers utan att skapa nya på varje render?
Det är sant, den heter UseEvent tror jag.
Den löser ju hela det problemet.
Ja, exakt. Så där behöver du inte just callback-wrappa saker utan den gör typ det.
Och den saknar också dependency array, men de gör magi i bakgrunden.
Som gör att värdena i den är alltid uppdaterade med den rendering den körs på.
Så det här vi pratar om är lite tillbaka på closures och grejer.
Men det är väl typ en ljus callback i bakgrunden fast med lite syntaktiskt socker ovanpå.
Det jag tar med mig från det här avsnittet är att jag måste läsa på "closures" igen.
Och jag vet inte hur många gånger jag läst på om "closures", men det bara försvinner.
Jag tycker också att det är väldigt svårt. Jag kanske har förklarat det lite halvförenklat också tror jag.
Men jag tror att folk fattar.
Det är väl hela grejen med den här lexikala scope och grejer och gamla grejer med "this" och vad den refererar till och hejsan och fejsan.
Så det är hela balen och balunsen med det där.
Ja, det finns ju väldigt mycket saker i bakgrunden som hör ihop.
Men känner du dig tryggare nu? Kommer du gå tillbaka och riva bort alla just memo och just callback?
Nej, jag känner mig ju lite duschigare för att jag sitter här och snackar skit.
Det är bara att jag har suttit så mycket i mitt egna huvud och varje gång jag lyfter frågan så säger de "How do you mean? Why?"
Och då säger jag "I don't know exactly"
Och så läser jag en till bloggpost från någon som tycker någonting
Det är som att jag är fast i någon snurra och kommer inte ur den
Nej jag kommer inte rycka, alltså speciellt, jag har ryckt några
Det har jag faktiskt. Samma har varit väldigt små som jag inte tycker tjänar någonting till.
Jag har flyttat bort alla conditionals och lagt dem under alla hooks.
Det var ju mycket så att det var conditionals för GraphQL, Unroop och sådana grejer.
Men jag har faktiskt också tagit bort Self-Invoken Functions.
Mest för att jag tycker att de är fula men också för att det kändes som att det var ett gammalt sätt att skriva JavaScript på.
Men det är väl inte fel?
Nej, men det blir lite mer lättläst om man inte skriver så.
Alltså det är väldigt argumentemått.
Det är också så att jag har gjort en konstant som en "arrow function" mitt i och sen kallar jag på den.
Det är inte supertydligt.
Nej, absolut. Men jag tycker ändå att det är tydligare än en "iffy".
Ja, men det är väl liksom...
Det är nog mer att jag hela tiden tvivlar på om jag är lite korkad.
Det tror jag faktiskt inte. Det tror jag absolut inte.
Hade du varit lite lite korkad tror jag att vi hade kommit till 58 avsnitt. Eller vad fan vi är på nu?
Vadå? Jag snackar ju bara. Vad är problemet?
En sak jag tänkte på som kan vara en rekommendation som jag tänkte vara på också generellt.
När du sa att den här ES-Lint-regeln var disabled. Har du enablat den igen?
Nej, vi satte den på "warning", men sen fick jag en fråga igen om mina PR.
"Do you know why all these complaints about this?"
"Kan du kolla dem?" Då orkar jag inte.
Ja, jag fattar.
Jag tänker att det är bra, särskilt när man kommer in i en sån här lite kodbas som man inte har suttit med själv.
Jag skulle ju sätta igång regeringen, men sen ignora alla befintliga fel.
Jo, jag vill också göra det, men då finns det de som är av den fasta ståndpunkten, även efter argumentation om att det är ett anti-pattern att stoppa in allting i dependency-arrayen.
För vissa gånger vill man bara köra det on mount och så vidare.
Ja, det är kriget. Den dagen.
Jag vet. Jag laddar. Min senaste laddning kommer att vara för att försöka att inte deploya automatiskt till production on Merge to Master.
Eller Merge to Main.
Ja, den skulle vi också kunna prata om. Men vi har lite slut på tid.
Jag tycker det var superkul. Det här är sån här detaljer och nitty gritty details som ändå är jävligt kul att prata om.
Det är också för att jag behövde lufta tankar från mitt jobb och gjorde det i en podd.
– Ja, det är perfekt. Det är därför jag sitter här med dig.
– Ja, toppen.
– Tack till alla som lyssnar. Hoppas ni också har en trevlig sommar, för det har vi.
Och så hörs vi om två veckor igen.
– Det gör vi. Ha det gött. – Bye bye.
– Bye.
[Musik spelas]
[Musik spelas]
Tack!
