82. Sluta hata på mina beroenden
lyssna! 
Anton stör sig på Remix framtida, platta, filstruktur men Therése vacklar lite kring vad hon egentligen gillar så med det som utgångspunkt blir det snack om mappar, namngivning, öronvrår, att uppdatera paket och tunnelexporter. Dessutom en hel del om åttio beroenden, att ändra i 1600 filer, co-location och mycket mycket annat.
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
Tack till Arizon för avsnittets skämt!
Länkar
Avsnittets skämt:
Vilket rengöringsmedel använder Linux-sysadmins?
Vim
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Vilket rengöringsmedel använder Linux sysadmins?
Jag har ingen aning.
Vim?
Nej jag vet inte.
Med brasklappen att den tyvärr numera bytt namn till GIF.
Det är så jävla smalt.
Jag vet, inlämnat av vår lyssnare som jag vet inte om det är, men instanicket är Arizon. Jag vill säga Arizan. Det låter rimligare att det ska vara Arizan.
Det låter rimligare med Arizan, absolut.
Men i alla fall, tack så mycket.
Tack, det var smalt. Jag fixade, men det gör ju i stort sett alla skämt.
Men alltså, Vim var ju inte smalt. Det var väl liksom standardrengöringsmedel för?
Jo, men man ska komma ihåg det också. Såg jag ju liksom, det är lite yngre än dig, du vet.
Ja, från tiden man kollar på reklam. Alltså, det finns en...
Nu kommer det en jättekonstig historia, men det finns hemma, när Yes-reklamen kommer på tv,
På tv så uttrycker Fredrik alltid sin besvikelse över att det är ny reklam och inte den här gamla reklamen där det är en snubbe som är dubbad och han bara ""Det är klart, schabben ska diska!""
Alltså vad i helvete?
Åh herregud. Okej hörni, välkommen till ett nytt avsnitt där vi pratar diskmedel.
Du kommer behöva hitta den här på Youtube nu och länka.
Absolut, jag ska göra mitt bästa.
Jag ska göra mitt bästa, eller åringet.
Jo, så här.
Jag har suttit några dagar med,
några dagar var jag nere vid drift,
men jag satt typ två timmar igår.
Och bumpade massa paket.
Jag uppgraderade massa paket i ett projekt.
Jag kanske uppgraderade 80 i beroenden.
För det första får man en reality checkad, som är varför i helvete har jag 80 direkta beroenden i det här projektet.
Men de är vettiga, jag har lyckats ta bort något.
-Vad är det för projekt? -Det är Fredagslunchen fortfarande.
-Har du 80 beroenden i Fredagslunchen? -Ja.
-Men hur? -Jag vet inte.
-Men är det direkta? -Det är dependencies och devdependencies.
- Det är 80 totalt. - Okej, men hur många är dev-dependencies?
- Säg... 75... nej, men säg 30. - Har du types?
- Ja, några av dem är types. Inte så många. Sju stycken typ.
- Okej, men ändå. - Jo, men sen är det också att ganska många av de här
dependencies är att det är... Jag vet inte hur många vi har, men Radix,
Där är varje komponent ett eget mp1-paket.
React-aria och React-state är också samma sak, fast det är helper-funktioner.
Men allting är uppdrappat i ett småpaket.
Så det är mycket sånt.
Det är inte så stora paket.
Men, vad fan var det vi skulle prata om?
Sluta hata mina beroenden.
- Ja, men jag bara hörde lite, för jag var tvungen att googla fram Youtube Yes-reklamen.
- Ja, det var det. - Så att vi vet att du har den.
Och då hörde jag det bara lite i öronvrån höll jag på att säga.
- Ja, men det finns. Öronvrån finns.
- Ja, och då blev vi chockad. Det är allt. Förlåt, fortsätt nu.
- Nej, men för det första så fick jag vilja piss och sitta uppe och träda beroendan.
Helvete vad trött jag blev.
Ja, alltså riktigt riktigt tråkig uppgift.
Det blev lite enklare för att det finns något paket som heter MPM Check Updates.
Som var ganska trevligt. För det första så får du en lista på vilka paket har Patch-uppdateringar, vilka har Minor och vilka har Major.
Och så hoppas man att alla följer Semantic Versioning.
Sen kan man använda den för att uppdatera alla paket som börjar på Radix till exempel.
Och så sköter den det åt dig. Och det var ganska trevligt.
Men det var fortfarande ett jävla helvete så fort man kom upp till major versioner.
Jag var tvungen att gå igenom allting och kolla vad som har ändrats.
Kommer någonting gå sönder?
Jag har ju inga tester.
Många har fruktansvärda changelogs också.
Ja.
För att jag sitter i ett team nu också vars en arbetsuppgift är, eller ska bli, att bumpa alla dependencies för hela projektet.
Så det är kul.
Ja, det låter jättekul. Grattis.
Inte alls läskigt.
Nej.
Men i vilket fall, jag lyckades ta mig igenom det här. Det gick okej, men det tog tid.
Det här är ett remixprojekt och då uppdaterade jag Remix det senaste.
Remix håller på med att förbereda för en major version.
Så de är på 1.16 eller 1.17 och håller på att förbereda för en v2.
Och då gör de det genom att de har i sin Remix-config lagt till att du kan i ett objekt som heter ""Future""
så kan du opta in till Breaking Changes som kommer i V2 redan nu om du vill.
Det känns väl ändå ganska vettigt, det är inte så konstigt för skapar du ett nytt V1-projekt nu så är det default att du kör på de nya V2-sakerna.
Jag har inte kört de där V2 sakerna tidigare.
När man uppdaterade nu så började man få massa varningar.
Varje gång du startade applikationen så fick du massa varningar.
""Future change warning""
""Opta in till den här grejen för att slippa varningen""
""Gör det här och där""
""Så här funkar det"" och så var det någon länk till någon guide.
Det var också helt okej. Det ledde till att jag absolut inte kunde stå ut med de där varningarna.
För jag absolut inte behövde migrera till V2 just nu.
Men det kunde jag inte låta bli.
Så för att få bort varningarna så började jag göra det där.
Vissa funkade jättebra. Någon kände jag var helt idiotisk. Den skete jag faktiskt inte.
Men en sån de har gjort då som jag skulle vilja prata lite om.
För jag tror att de flesta kan relatera är att Remix har haft filbaserad routing på samma sätt som i stort sett alla andra ramverk nu för tiden.
Alltså det är samma sak i Next, att du har dina mappar och du nästlar dem i den och så får du ut en URL, en path baserad på vilken mapp saker ligger i.
Om du har ett dollar i Remix, så är det en variabel eller en parameter.
Det är i stort sett som Next har det också.
Och det jag skulle komma till till slut.
Nu i V2 så har de ändrat något som de kallar ""Flat File Routes"".
Det innebär att de tar bort alla mappar.
Så om vi säger att i Remix kan du ha nästladde eller layouts som du även kan i Nexts nya approuter.
Men du kan ha en layoutfil som är bara så här att alla routes under den här ska bara ha wrappat i den här komponenten.
Så att säga att du har en layoutgrej, förut hade du en layoutmapp och sedan i den kanske du hade en indexfil och sen så låg det en till mapp i den som kanske var admin eller något.
och i den var det typ någonting som hette en index eller en route-fil som var liksom lövet i trädet.
Nu när det här ändras, då blir det istället att istället för att man har en massa mappar, då har du liksom en fil som heter layout.admin.index.t6.
Okej, men då kommer du ju ha massa filer som har samma patronym i början. Är det verkligen bättre?
- Alltså vänta, jag ska bara skicka den här bilden till dig så att du förstår.
Alltså om du får hålla på med den här bilden jag skickar till dig.
Där är mina routes i projektet nu.
- Ja precis, det var exakt så som jag uppfattade det innan du skickade den här bilden till mig.
- Ja, det var bra. Så det är liksom massa filer som bara ligger platt.
Och på något sätt så gillar jag att det är platt.
Men det är ju fan svinjobbigt när det inte går.
Jag hade hellre velat ha nästla halvvägs.
I stort sett alla mina filer börjar på layout.
För att det är en layout.
Det är ju Rappern som alla routes använder.
Då hade jag hellre haft en mapp.
Du har ju en MDX-fil bara.
Ja, det finns också. Det är för att remixa stöd för Markdown.
Eller MDX och nästla, eller en del av routes från.
Men den här layout-grejen, då skulle jag bara vilja ha en layout-mapp istället.
För jag bryr mig ju inte om att alla innehåller layout.
Nej, det här tycker jag kändes lite stökigt.
För nu blir det ju, som jag säger, det blir väl jättemånga...
Om du har flera admin, layout och admin, bla bla bla, layout och admin, bla bla bla.
Alltså... Och jag är ju en person som har jävligt svårt för att navigera saker på det här sättet.
För att allting jag läser flyter ihop.
Om man kollar i mitten så finns det typ 10 filer som heter layout.groups.dollargroupid.någonting.
Det är detaljsidan för en grupp och sen finns det en massa undersida till det.
Jag satt och försökte migrera det här igår och bara ""Varför gör jag det här? Det här känns idiotiskt.""
Ja, jag vet inte det här tycker jag inte. Och sen har du API här. Då hade det varit nice att ha en layout-mapp och en API-mapp.
Det är tydligt, det är två mappar.
Gud ja, det hade varit svimbra.
Och jag tror att någon argumentation för att man kan göra så här är att du skulle kunna, istället för att alla de här filerna var rena filer,
Då skulle du kunna döpa dem till en mapp som heter samma sak.
Och sen inuti den mappen lägga en index.t6 eller en route.t6.
Deras argumentation är att då kan du också co-locata med saker där.
Så skulle du ha så här, det här är CSS som är specifik för den här routen, då kan den ligga i den mappen.
Om du har komponenter som är specifika för den här routen så kan de ligga i den mappen.
Visst, det lockar lite grann.
Men jag tycker fortfarande att det är så jävla svårt att få en överblick av och svårt att hitta vad fan jag håller på med.
Jag tror inte jag uppskattar det här alls, men då skulle jag säga att jag också just nu sitter i Next.
Men däremot så tycker jag att det blir lite skönt att slippa, för jag ser ibland att man gör en route och så har man en map.
Och så heter det någonting och i den mappen finns en indexfil och sen ingenting mer.
Och då är det lite så här, då hade vi inte behövt mappen, då hade vi bara kunnat döpa filen till det.
- Ja, absolut. - Det stör mig lite grann.
Det håller jag med om. Man vill ju undvika indexfiler så gott det går egentligen.
Ja, men folk det är, de älskar indexfiler.
Jag vet inte, sen såg jag att det fanns ett paket som man kunde uppgradera till v2
men ändå behålla den gamla strukturen som var officiellt från Remix hållet.
Men då känns det också så här, vill jag verkligen använda Remix om de säger ""Nej, det här är vårt officiella sätt att göra det på""?
Man vet ju med sådana grejer att till slut så kommer det sluta supportas.
Och till slut så kommer det vara så här, vi har optimerat för den här platta strukturen.
Samma sak så här, det funkar att köra klasskomponenter i React idag.
Men funktionskomponenter är ju det som är rekommenderat.
Det känns bara mäckigt.
Det fanns också ett tredjeparts integration till Remix.
Som var att du kunde få typ platta routes, men du kunde få de här halvväg så att du kan ha layout RN-mapp
som innehåller massa filer och API var RN-mapp som innehåller massa filer.
Så kanske att jag sträcker mig efter den, men jag vet inte, jag tycker bara att det känns jobbigt.
Men det är också kul, då kommer jag inte använda det här bla bla, alltså kul.
Alltså jag är ju inte så opinionitet, jag hade ju bara så här, det här är sögväll, men jag hade ju bara använt det.
Jo, precis. Men jag tänker att det här är väldigt mycket sidoprojekts perspektivet.
Alltså då hade jag liksom så här, ""Åh, nästa gång jag gör någonting, då kanske jag inte använder Remix för att jag hatar dras routing.""
Jo, men då är det också bara ett sidoprojekt och inte ett riktigt projekt.
Ja, absolut. Du tänker att det är inte så mycket att vara upprörd för.
Ehh, för dem kanske inte det är värsta att personen som gjort sitt sidoprojekt inte använder Dreamweaver.
Det kanske det är.
Det vet inte jag, men det lär ju också finnas personer som älskar det här.
Det är en tydlig överblick över alla routes jag har. Jag kan tydligt följa dem.
De är inte dolda i fil eller i mappar. Jag måste följa upp varje mapp för att se mina paths.
Utan de är här, rakt här.
I ditt blickfång.
Jo, det kanske är en vanlig sak. Det vet jag inte.
Det kanske bara är det. Jag är så van med att det ska vara baserat på vilka mappar det ligger i och vad de heter och vilken struktur de har.
Men det är också så att jag tänkte på det här en dag.
Nu händer inte det jätteofta men det känns också som att om jag ska flytta någonting nu, då blir det istället att byta namn på det.
Eller om jag vill byta URL-strukturen på ett gäng filer så måste jag byta namn på alla filer.
Jag vet inte, jag tycker det känns...
Jag är inte såld, så att säga.
Jag börjar ändå gilla det.
Ju mer du tittar på den här bilden.
Ja, en klassisk printscreen.
Men ändå, jag gillar det på något sätt.
Nu har jag funderat mycket på det här, för jag söker upp alla grejer.
Så då blir det så här, okej, men omsidan.
Sen så måste jag flippa omkring i alla mappar.
Då i VS Code skulle jag kunna söka upp den filen,
bara köra Command + Shift + E,
och sen så är hela filstrukturen där,
ser alla paths som finns, som är typ samma.
Det hade nog givnat mig, tror jag.
Jag vet att jag föredrar väldigt mycket själv.
Att istället för att ha komponenter i olika mappar.
Att man delar upp dem i olika, vad de är för någonting.
Du kanske har en grupp, eller en mapp med komponenter som har med grupper att göra.
En mapp med komponenter som har med användarna att göra.
Det tycker jag är oftast ganska värdelöst.
Jag är så här, dumpa alla komponenter i en mappa då.
Så man kan se allting samtidigt.
För jag tycker det är så här, man söker ju upp dem alltid.
- Ja, men sen så jobbar jag ju med människor som verkligen, verkligen jobbar med filträdet.
Så jag kan väl förstå att det blir en diskussion.
För att nu kommer det kommer komma en liten diskussion liksom
hur vi ska använda Common Components-mappen.
För att vi har väldigt mycket svaret på det här.
- Där har vi också, Common. Vad är det? Common?
Exakt, vi har ju strukturen att vi har en page och i den pagen så har vi direkt en komponent.
Så det finns liksom en page-komponent.
Så alla de har egna filer och sen har man en common map.
Och då kommer en diskussion om man liksom borde ha något, det heter inte prefix, vad heter det efter?
Suffix.
Det är ett suffix för de komponenterna.
Om det finns en mypage-route så finns det en komponent som heter my.
Men då kanske den i stället skulle heta myroot.
Och sen så kommer det en diskussion om vad common filen är till.
Det blir mycket så.
Och jag tror att det kommer mycket mer från personer som rör sig i filträdet.
Jag bara söker efter allting. Jag rör mig inte i filträdet.
Jag söker efter precis allting. Men när man är precis tvärtom, då förstår jag att de här sakerna helt plötsligt spelar lite större roll.
- Ja, men så kan det nog vara.
Det krävs ju att man är lite bekant med en kodbas för att man ska kunna börja söka också.
Jag tycker att man har en components-mapp som innehåller alla komponenter, rakt upp och ner, platt, rakt ner i mappen.
Jag tycker att det kan ge en ganska bra överblick.
Plus att det tvingar en att se till att de har ganska bra namn.
Ja, men det beror på hur många komponenter man har.
Jag försökte göra det här där jag bytte default-export till named-export.
Så jag la upp en PR på det och så fegade jag ur för jag vågade inte mer än.
Jag hade alltså ändrat i 1600 filer.
[skratt]
Så jag menar, det är inte så bra att ha en radda...
[skratt]
...bara en radda 1600...
[skratt]
...komponenter.
- Eller är det? - Nej!
[skratt]
Nej!
[skratt]
- Nej. - Jag förstår vad du menar.
Jag tycker det är bra att ha alla platt bara.
Alla liksom, som är längst ut.
Men saker som används i dem, de tycker jag kan få klättra ner ett träd i dem.
Typ.
saker som används i komponenterna, tänker du?
Ja, precis. Om den här sidan har en komponent som heter ""heading for""
""a fancy heading"" komponent som bara används i den komponenten, då kan den få ligga som barn, tycker jag.
Ja, just det.
Och där kommer då ""common"" in igen.
Absolut.
Nej, det kanske beror på, för jag är också väldigt mycket för, alltså nu känner jag att jag liksom
Jag talar emot mig själv lite grann, men jag är väldigt mycket för att co-locata, som jag inte vet vad det heter på svenska, men
saker som hör samman.
Men det känns också som att det är väldigt sällan saker hör så jävla mycket samman.
Det beror kanske på hur man gör.
Jag kör ju mycket CSS inges libbar så då hamnar saker tillsammans i samma fil oftast.
Men hade man haft till exempel
en .css-fil som hörde ihop med varje route,
Det hade varit väldigt trevligt om de låg på samma ställe istället för att de skulle ligga på olika platser.
Men vill man verkligen ha andra saker i routes-mappen än filerna som ska vara själva routern?
Jag vet inte.
Blir inte det routes?
Nej, det blir ju inte routes för att de har löst det.
Men om det ligger andra JS eller TSX-filer där i så blir det väl ändå routes?
Nej, de måste heta på specifika sätt.
Vad menar du?
I Remix exemplet, om du har en layout.
I mitt exempel finns det en layout.about.tsx
Om man skulle vilja co-locata den med en CSS-fil så förstår jag det som att du byter layout.about
blir en mapp. I den ligger en fil som antingen heter index.t6 eller route.t6.
Det är bara de filerna i de här mapparna som blir routes.
Och sen i vad du lägger i mappen i övrigt, det kan vara vad som helst.
Där kan du lägga CSS och komponenter och allt möjligt även om det är t6 eller j6 filer.
Men det är då för att de har en standard som är att om det är en mapp nu
i den här platta strukturen.
Då måste
route-filen inuti den
heta route.t6 eller
index.t6. - Men om det inte är en
platta? - Ja då går det väl inte.
- Eller om det är index.js? - Alltså i Next går det väl inte.
Såvitt jag vet. - Nej.
Det var ju det jag menade. - Ja men jag
pratade bara utifrån Remix, herregud.
- Åh men gud.
Gud. - Nej men i Remix
eller i Next går det väl inte.
- Nej men minst.
Nej, precis. Det är väl det, att man inte kan lägga massa saker i Next.
Nu vet jag inte hur det är i Next 13. Det vet jag inte.
Nej, i approuten tror jag att det är samma sak där faktiskt.
Nej, men skitsamma. Det känns som att jag har varit inne på mappstruktur förut.
Men jag är så himla kluven. Jag brukar bara försöka sälja mig till...
Det enda jag verkligen kände att det var numera en kulle som jag var beredd att dö på var Named Exports.
Och där dog du inte ändå?
Jag fattar inte det.
Jag har tagit bort regeln i alla fall.
Okej.
Jag förstår till exempel inte det här med en indexfil i en komponentmapp.
Där man bara exporterar saker.
Jag förstår att det blir en kortare path i importen.
Det förstår jag också, men det blir också 5 miljoner indexfiler som du måste uppdatera om du uppdaterar någonting i.
Jag förstår inte den grejen till exempel, men om jag är på ett ställe som vill ha det här, då följer jag ju det.
Ja, exakt. Det är inte en kulle du dör på.
Nej.
Jag vet inte, jag tror att jag har fått för mig att jag har lärt mig att det kallas för ""barrel exports"".
Jag vet inte riktigt varför, men jag håller med. Jag tycker att de är helt värdelösa.
Jag tycker inte att de ger mig någonting. Alla IDE- eller kode-editors idag har ju AutoComplete på allt sånt här.
Så du tjänar ju ingenting på att ha dem.
Nej, jag vet inte heller. Däremot så gillar jag ju nu att jag har Styling och Test tillsammans med komponenten.
Jo, men test känns man vill ha när och där det är test.
Jag vet inte vad jag vill komma med det här.
Ingenstans tror jag.
De här remixroutsen, de flatroutsen växer fan på mig.
Däremot sådana här som underscore, som layouten.
Den hade kunnat vara en map, men tänk att bara fälla upp den och få alla paths.
Men i och för sig, jo. För den är inte med i pat-namet.
Nej, precis.
Så det...
Ja, jag vet inte var jag kommer att landa i det här.
Jag funderar på om jag ska testa det här tredje parts-libbet som man kunde integrera med Remix
så att man kunde få det vi nu pratar om nu.
Men då känner jag också så här, routingen känns som en jävla stor kärna i vad ett ramverk gör.
Så vill man gå ifrån det de rekommenderar?
Det är också helt sjukt att en sån här sak skulle kunna få dig att inte använda en grej.
Jag hade brytt mig så lite. Jag hade bara så här, ""ja, men då är det väl så här jag gör det.""
Ljusläst dokumentationen, kollat på en tutorial, varit så här livrädd för att sticka minsta tå utanför the line.
Så jag bara, ""då gör jag väl så här?""
Ja, absolut. Jag känner också att jag snöade in på det här, fast jag inte behövde ta det här beslutet nu.
Jag hade kunnat lämna det som det var, för det var ju bara den här varningen som jag störde mig så mycket på.
Ja, absolut.
Samtidigt så tycker jag att just hur Remix hanterar att det kommer ""breaking changes"".
Vi har bestämt oss för att det kommer ""breaking changes"" i framtiden.
Du kan köra dem redan nu. Det tycker jag känns ganska trevligt.
Ja, det får man väl tycka. Men hur kommer saker ändras ändå sen?
Kanske man har gjort det här jobbet i onödan.
Jag tror att deras filosofi är att det här är saker som är spikade till nästa ""breaking change"".
Men jag vet faktiskt inte.
Jag tycker det funkar helt okej men jag skulle också vilja kunna stänga av de där varningarna utan att behöva göra massa skit.
Jag stör mig för mycket på sånt där.
Det är samma sak med ES-Lint varningar. Det stör jag mig också jättemycket på.
Man ska inte ha varningar. Antingen får man ha errors eller så får man komma över det.
Ja, fast jag vet inte. Typ oanvända imports.
Men ta bort dem bara.
Jo, men jag tycker att de kan ligga som en varning för att när man utvecklar så händer det ganska ofta att du har en import eller du kommenterar ut lite kod.
Och då är det så jävla irriterande om importen försvinner för att du måste ta bort den eller att du får ett error som gör att bygget failar när du bara sitter och har kommenterat bort lite kod som använder en import.
Ja, déjà vu. Till en tid då vi satt i ett projekt och någon alltid tog bort den här regeln.
Och sen lämnade fem miljoner imports. Oanvända imports.
Jag förstår din poäng, men sitter du i att kommentera ut dem eller ta bort dem och sen importera dem med command punkt?
Ja jag vet, det är inte värnligt men det var enda exempel jag kom på att man kanske behöver ta varningar på ESLint.
Ja, konsolloggs kanske. Du ska inte höra om det, men ibland vill man höra om det.
Ja, det är sant.
Det är lite jobbigt att man ska köra någon ""disable"" kommentar varje gång man ska konsollogga också.
Ja, eller om man vill gå från ""default export"" till ""named export"" kan man sätta en varning, men det fick man inte för då hade man 1400 varningar i loggarna.
Jag tycker du ska ge det till försök.
Nej!
Jag tycker verkligen att du ska pusha igenom den här ändringen.
Nej men det var för läskigt.
Som för typ tre eller fyra avsnitt sedan, då kommer du att ha gjort lite gott för världen.
Ja absolut, det är verkligen gott för världen. Man bryr sig så mycket.
Nej men det var för läskigt, saker gick sönder och jag kunde inte reda i det.
Det är för obakligt.
Jag är super nyfiken på att höra om folk har testat sådana här Flat Routes. Jag vet inte, det kanske finns något annat ramverk som kör platta routes istället för mappbaserat.
Men jag är nyfiken på att höra om folk faktiskt gillar det. Jag har inte kommit dit än i alla fall. Så vi får se om jag återkommer om det här i framtiden.
Ja, och jag sitter ju bara här som en utomstående observer och tittar på en screenshot, men jag gillar den då.
Ja, exakt. Du är liksom såld redan efter ditt screenshot.
Ja, men just för att jag inte behövt skriva dem själv.
Och för att det är väldigt tydligt för mig vad det har för routes.
Förstår du hur mindfucket det var när jag skulle döpa om alla filer som låg i olika mappar till de här platta filnamnen?
Alltså jag förstod ingenting, det var helt omöjligt att hålla det i huvudet samtidigt.
Jag förstår inte hur svårt det kunde vara.
Men hur svårt kan det vara? Jag fattar inte. Vad är det som är svårt?
Nej men det var liksom, det är inte så svårt utan allting var ju ungefär som man hade tänkt sig.
Och sen fanns det något nytt edge case, att saker skulle heta ""_index"" i slutet ibland.
Och det fuckade allt.
Alltså jag förstod, det blev så mycket buggar.
Och det blev liksom, det tog sån tid.
Så det kanske också har färgat min åsikt om den här platta finspekturen.
Men, helvete vad läss jag var ett tag.
Ja, det kan absolut ha färgat. Jag älskar att jag sitter här på min höga häst.
Och det känns som att om jag ger mig på det här, då kommer jag liksom trilla av direkt.
- Alltså jag önskar att du får ge dig på det här någon gång.
För då kommer jag komma ihåg, jag kommer liksom klippa in när du säger ""hur svårt kan det vara?""
- Hahaha, men det ska också sägas att jag är ganska bra på repetitiva döda...
Döfödda? Döda?
Repetitiva, monotona uppgifter där man inte använder huvudet så mycket.
För att alltså det är det enda jag kan.
Du kan innovera, jag kan göra repetitiva saker.
Så, så mycket.
Men det känns repetitivt och monotont.
Jo, det var det faktiskt.
Ja, ja. Vi avslutar där.
Och sen så får vi väl se vad fan som händer med den här platta filstrukturen.
Och där avsnittet, jag vet inte ens. Jag vet inte.
Nej, men som vanligt, vi finns där vi finns.
Ge oss gärna en...
Fan, vet du vad jag måste säga?
Våra lyssnare är ganska dåliga på att ge sig recensioner på iTunes.
Absolut. Har du någonsin gett en recension på iTunes?
Jag har gett recensioner till mina egna poddar varje gång jag haft någon.
Har du gett en recension till den här? För jag har inte sett det.
Jag tror inte jag har skrivit något, men jag har gett en femstjärnor.
Jaha. Vill du inte ha skrivna recensioner? Är inte det du eftersöker?
Jo, jag vill ha skrivna recensioner, men de får ju också gärna vara positiva.
Nu kommer vi bara få en massa hat när jag sitter och säger att folk är dåliga för det här.
Ja, vi glömmer det där hörni. Vi hörs igen om två veckor.
– Det gör vi. Ha det bra! – Bye bye!
– Hej!
[Outromusik]
*outro*
