29. Sassy CSS-in-JS-modules
lyssna!
Vi pratar om olika sätt att skriva CSS. Allt från en gammal klassisk index.css till BEM till preprocessors till CSS-in-JS och CSS modules. Mycket om att undvika “kaskaden”, specificitet och att namnge saker. Vi diskuterar att det fortfarande är viktigt att skriva CSS “som det egentligen ser ut” för att inte abstrahera för långt även om en skriver CSS i JS. Dessutom en del om filstruktur, separation of concerns och att skriva kod utan sina verktyg.
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
- Less
- Sass gamla syntax
- Sassy CSS (den nyare syntaxen som förvirrande nog kallas Sass idag)
- BEM
- Pug
- styled-components
- emotion
- stitches
- JS template literal
- CSS modules
- Material-UI
- Code in the Dark
- CSS kursen Anton köpt
- RIP IE11
- CSS Container Queries
Avsnittets skämt:
Vad dricker webbutvecklare helst när de är på event?
Nått som bubblar.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att
klicka precis här :)
Vad dricker Frontend-utvecklare när de är på event?
Hmm, vi har ju haft favoritet tidigare, men på events just?
Ja, det är något med ström, kanske, jag vet inte.
Något som bubblar?
Ja, okej.
Jag började tänka alldeles för inte webbutvecklare. Jag började tänka på eventbuss och massa grejer.
Ja, men eventbubbla är ju.
Ja, det var bra. Klassisk nivå så att säga.
Jag vet inte hur jag ska ta det där. Jag får bara ta det och gå vidare. Välkomna till ASDF allihopa.
Ja, allihopa. Du som lyssnar.
Idag tänkte vi att vi skulle snacka lite CSS, men kanske inte bara plain CSS.
Vi pratade lite CSS tidigare. Men typ alla olika sätt man kan skriva CSS.
För det finns ju idag ganska många olika sätt. Och många sätt är ju liksom
försöka att fixa de problem folk tycker att CSS har.
- Ja, för det är ju, på något sätt så går vi mer och mer mot att sluta behandla CSS som CSS och mer som, ja, script, eller vad man ska kalla det.
Man jobbar ganska hårt från att frångå hela Cascading-grejen som är Cascading-style.
Vad är det sista?
- Shits.
- Just det. På något sätt.
- Ja, exakt. Det känns väldigt mycket som att vi går från CSS till bara SS.
Man vill bara ha style-shits. Man vill inte ha hela Cascading-grejen.
Det är väl det största problemet. Men sen också det här med specificiteten som är en del av Cascadian.
För att kunna bestämma vilken regel som applicerar just här.
Ja, det är intressant. Det är "important" överallt.
Ja, men exakt.
Men jag tänker liksom att det känns som att det har tagit en jävla resa.
För att när jag började i alla fall, då skrev jag ändå CSS i bara...
Det var en index.css-fil, så stoppade man in allting man hade där.
Och det var liksom... Ah, det funkar fint.
Då var det inte i någon typ av professionell kontext, vilket kanske påverkar.
Men ändå så var det så.
Första sättet man lärde sig CSS var att skriva CSS helt plain.
Efter det kom man in på lite mer preprocessors, i stil med less eller sass.
Eller sassy CSS.
Det var som en uppenbarelse för mig.
Äntligen slipper jag skriva nästla saker.
Bara det gjorde det så jäkla värt att köra det.
Men jag vet inte, hade du samma väg, har du också kört både LESS och SAS eller SASI eller vad fan det heter?
Inte SASI men jag har kört både LESS och SAS.
Det är precis som du säger, när man ens tänker på det, nu kan jag nästan ha problem om man ska slänga ihop något litet.
Då kan jag nästan fastna i att så här, jaha just det, CSS utan en preprocessor, då får jag inte nästla saker.
Det känns så främmande för mig nu, för att det har jag på något sätt alltid gjort sedan jag började jobba som utvecklare.
Men jag kommer också ihåg, för även om man då fick nästla saker så hade man ju fortfarande det här problemet med att det kunde påverka över hela projektet.
för att just Cascader och vad är mest specifikt och sådana bitar.
Jag kommer på något sätt ihåg när BEM revolutionerade.
Jag har aldrig kört BEM egentligen, för jag tyckte att det där kan man väl lösa ändå.
Det gjorde man inte, men jag vet ungefär vad det är.
Jag tror att det står för Block Element Module, eller något i den stilen.
Eller Block Element Modifier.
Just det, för det var ju hur man döpte grejer bara va?
Ja, precis. För då hade du vilket block du var i, alltså en block på sidan.
Vilket element specifikt var du satt klassnamnet på.
Modifieren röd, eller kanske inte röd, kanske "error" eller "approved".
Alltså det var den som satte den här sista, allt annat var likadant men det var något som stack ut som skulle modifieras.
Ungefär så var det länge sedan.
Ja, just det. Jag tror att jag har lite i projektet nu, lite lämningar som är att det är uppdrag efter BEM-syntax.
Men visst, fanns det någon tooling runt BEM också? Eller var det bara "Okej, vi ska döpa saker så här"?
Jag är inte helt hundra... Jag är inte säker på att det var så mycket tooling, men jag tror det fanns principer som man skulle följa.
Vad är ett block? Vad är ett element? Vad är en modifier? Sen vad är den här du ska ha?
Vad var det mellan block och element? Vad är underscore? Och sen modifieren, vad är dubbeldash?
Så det fanns ju konventioner att följa.
Men jag vill inte minnas att jag suttit med specifika verktyg.
Men det är ju mycket möjligt att det fanns.
Eller finns.
Ja, precis. Därför har jag också fått för mig att det bara var en namnstandard i stort sett.
Ja, jag tror också det.
Jag kommer ihåg att jag haft jättemånga diskussioner.
"Vad är egentligen en modifier? Och vad är blocket? Vad går gränsen på blocket?"
Alltså så här timmar som har försvunnit in i det hålet.
Ja, för det är ju ett av de kanske äldsta stående skämten inom utveckling att namngivning är väl det svåraste man kan göra.
Ja, det är ju inte fel.
Nej, jag håller med. Det är ju extremt svårt faktiskt.
Jag har också skrivit mycket less och sass.
Det tycker jag är lite svårt.
Det fanns ju både sass och sass i CSS.
Det var någon variant på sass.
Nu kommer jag inte ihåg vilken.
Men den ena var ju typ som vi tänker att sass är idag.
Det är typ nestling och lite mer socker ovanpå.
Den andra var att du tog bort måsvingar och fan vet allt.
Oj, det har jag inte stött på.
Den följde väl bort lite grann för den skrevs kod som var så olik CSS.
Och lite liknande grejer, det fanns också något som heter Pag HTML.
Då skrev du typ HTML, fast utan krokodilmunnarna eller taggarna.
Om du skulle skriva ut en div som hade en klass, då skrev du bara div.klassnamn.
Och då processade den där så att den blev en div.
Och sen var det typ nestlingen, eller inte nestlingen, men typ indenteringen
som avgjorde vad som var nestlat inom varandra.
Oj, okej. Ja, det känns inte superläsbart, eller?
Nej, det blev ju mycket mindre text att läsa.
Jag vet att jag byggde liksom någon gammal Spotify-quiz-app för länge sedan i Vue.
Då körde jag Pug.
Och då var det ganska nice ändå. Men det var också för att du kunde köra dem i Vues-template.
Det blev ganska läsbart och då körde jag ändå Vues och då var det liksom "Varför inte lägga på ett till lager?"
Och det var också lite innan jag kände att man kanske ska försöka abstrahera inte allt för mycket.
Innan man lärde sig det så att säga.
Jag tror att någon av de här SAS-varianterna, eller om det var SAS i CSS, eller om det är den som lever kvar, var typ så.
Men det var också en grej som jag kände att "Nä, det här känns inte helt hundra".
Nej, det där har nog verkligen inte stött på.
Det låter tilltalade, men inte när du pratar om det här, kan jag ändå känna.
Nej, jag tror att de idéerna är ganska döda eller omoderna.
Men det vi pratade om sen var att namngivning är så svårt.
Och något som hyfsat löser det, i alla fall för CSS,
var när det kom CSS in JS, alltså CSS i javaskript.
För de som inte har kört det så mycket innan,
Du skriver din CSS som skriptobjekt på ett sätt.
Antingen kan du skriva att du har en styled component, som är den vanligaste.
Då har du en styled objekt som du importerar.
Sen skriver du "styled.div".
Då är div en funktion.
Sen skickar du in ett objekt till den, där objektet är din styling.
Och sen spottar den ur sig en komponent som du kan använda som får den här stylingen applicerad.
Då har den genererat upp ett klassnamn och allting åt dig som är då scopat till just den komponenten.
Så den stylingen kommer aldrig kunna appliceras någon annanstans.
Och det var ganska länge sedan det kom nu.
Det blev populärt för att i React så kan man skicka in styling som objekt också i style-proppen.
Det blir populärt. Men nu i fritiden skriver de flesta CSS/JS-bibliotek.
Då kör de något som heter template literal.
Som är de här... Jag vet inte vad de heter. Backticks, typ.
Man kan göra en multiline-sträng, är väl idén bakom dem.
Ja.
Då kan man göra smarta saker som att du skriver "styled.div" och sen skriver du bara...
Det ser jävligt skumt ut när man ser det för första gången.
Då ser det ut som att jag skriver "style.div" och så kommer det en textsträng direkt efteråt.
Det är liksom inga parenteser, ingenting. Och det ser så jävla konstigt ut.
Jag fattade fan ingenting i början när jag kollade på det.
Men det är någon kortsyntax för att skriva en funktion som tar emot en sådan sträng.
Och då kan man skriva CSS, om vi pratar CSS in JS, så kan man skriva CSS som
exakt ser ut i CSS.
Som om du skriver in CSS-fil. Och det är ju en stor fördel tycker jag.
Ja, och så en sån här template-grej. Det är lite som om man har stött på att skriva
på samma sätt kan man skriva GraphQL-frågor i JSX också när man använder en sån här template-backtick-grej.
Man trycker in hela frågan som en sträng.
Ja, precis. Det känns som att det har kommit ganska mycket på de sista åren i de moderna verktyg.
Då använder man template literals för att skicka in när man har någonting som inte är JavaScript, som ska vara text.
Så använder man sådana. Just idag finns det också väldigt mycket tooling runt omkring så du kan få syntax highlighting och
autocomplete och allt vad du nu vill inuti de här som är bara strängar egentligen.
Jag är lite, det känns som att jag har missat det här med style i JavaScript, i JS. För jag hade en mellantid här då jag körde rätt mycket CSS-modul.
Det blir ju en sån scoped CSS. Man kan fortfarande köra en CSS-fil, man kan fortfarande köra en preprocessor.
Men du skapar upp en stylefil per komponent egentligen och sen så importerar det som en modul.
Vilket du gör i din paketeringslösning och så. Så kan du lägga till att du hashar klassnamnen så alla blir unika.
Så det blir ju egentligen en enda stor stylefil men den blir ju namngiven så att det blir skapat per komponent.
Och jag tyckte ju det var ganska nice när det kom men det var ju säkert för att man gick från det här med hur ska jag organisera mina CSS-filer, hur ska jag göra det här och namngivningen och jada jada jada och vem och hur ska jag tänka det till att man bara kunde ha en fil per komponent.
Och sen så hade man liksom hundra component style filer där alla hade som yttersta klassnamn "component" eller "container" menar jag.
Så det blev många så, men det funkade och det var ändå ganska skönt.
Det var lite befriande på något sätt att allt inte behövde vara hundra procent namngivet.
Och sen blev det mycket så här att det går ju att jobba med det, att specifikt säga att jag vill att den här klassen ska vara global eller plocka in en förälder som är global och sådana här och lite sådana saker.
Så det gick ju att göra lite nya saker på något sätt.
Så det tyckte jag var ganska stort när det kom, eller inte när det kom men när jag började jobba i det skulle jag vilja säga.
Sen har jag väl kommit mer in på det här med Style Components eller Style i JS.
Men det jag inte förstår är om man tar Style Components och ändå delar upp det i två olika filer.
För det förstår jag inte riktigt. För jag tänkte att hela poängen med Style Components och sådana saker skulle vara att man hade det på samma ställe som sin JSX.
Jo, precis. Det skulle jag vilja säga att det är för de flesta fall.
Det beror lite på vad du bygger.
Bygger du någon typ av komponentbibliotek,
eller någon style guide,
då kan det vara att du behöver inte skapa upp komponenter
för att applicera någon styling, utan istället skapar upp en style component.
Det är lätt att säga style component,
Det var det första CSS/JS-libbet som blev stort i alla fall.
Jag säger nog det mycket nu bara för att jag sitter med MooIs egna sätt att styla och den heter ju Styled.
Ja, exakt. Jag tror att alla lib som har kommit efter det finns Emotion och Stitches.
Det finns extremt många som försöker göra lite varianter på det Styled Components gör.
Men för din fråga så är det lite så att jag brukar också gilla co-locata.
Om den här komponenten ska använda, dens styling, den kan typ ligga i samma fil.
Så länge den inte blir alldeles för stor. Då kanske man flyttar ut den till en fil som ligger bredvid.
Men i vissa fall kanske man vill lägga lite generiska styled components i en fil.
Om det är ett inputfält som vi bara har stylat.
Då kanske man vill kunna importera det från en plats.
Men att lägga exakt all styling om de är specifika för vissa komponenter känns inte supernyttigt.
Jag greppar ju den när man har generella komponenter eller generella styling som man vill applicera.
Det har jag också gjort. Det är ganska nice egentligen.
Det kan vara ett grid eller det kan vara specifik styling på en knapp eller vad som helst.
Jag har återanvänt det på flera ställen.
Det vill man inte ha en J6 för nödvändigtvis.
Det tycker jag är väldigt trevligt.
Men just den här att splitta upp det.
Man har ju fortfarande det här att man ska hoppa mellan två olika filer för att jobba ihop det till en komponent.
Det tänkte jag ju.
Jag kommer ihåg det var för länge sedan.
Var det inte någon blogg som blev stor om att vanlig CSS är död.
Nu är det bara CSS/CJS som är, har jag för mig att det blev lite kontroversiellt.
Det känns som att det har varit en del drama kring just CSS.
Ja, jag tror det kan ha varit väldigt länge sedan.
Men just den att, varför ska du ha det på flera ställen?
Du ska ha allt på samma ställe. Jag vet inte vad jag vill komma med här.
Ingenstans säkert.
Nej, men det är lite olika skolor kanske.
Alltså för att det man pratar om egentligen är ju,
och det vi kanske har gått mer och mer mot det som vi pratar om,
att man vill ha alkohol som berör en komponent till ett ställe.
Men tittar man tillbaka på när vi började kanske,
då var ju det här "separation of concerns" åt andra hållet då.
Då var det så här, okej, separera CSS, HTML och JavaScript.
Då var det de concerns som man separerade.
Men i själva verket, och det kanske är lite vertikalt, det blir lite silos av det, eller kolumner med olika grejer.
Medan nu har det svängt mycket mer och istället så pratar man om separation of concerns
på horisontellt, att vi delar upp separation efter att den här komponenten är en concern.
Och då vill vi ha allting som berör den komponenten, inklusive CSS, JavaScript och HTML, eller markup, på samma ställe.
Och det känns ju för min del som en oerhört vettig svängning i opinionen.
Ja, jag tycker väl fortfarande att det kan finnas...
Det beror på.
Och det är väl mer att det beror på liksom om det är...
Alltså det beror på hur mycket styling som ska göras, tror jag.
Men just den här Ron Jud skriver att om man kan skriva CSS i Style Component, så det kanske tilltalar mig.
Men det är också den här, när man har projekt som egentligen bara typ är fem divvar, men sen bara är styling, så känns det ändå så här jobbigt att skriva.
Det är templatespråk. Jag vill ha att den ska formatera åt mig och skriva ut saker åt mig.
Det är hjälp. Jag vill ha hjälp.
Du vill bara ha hjälp.
Jag vill bara ha hjälp.
Absolut. Jag tänker att en grej är väl att toolingen runtom styled components eller CSS/JS idag är så pass bra att du kan få allt det.
Oavsett vilket sätt du skriver på.
Det är väl kanske en grej.
Men sen håller jag med dig om att ibland kanske man vill...
Ibland kanske det är lite överdrivet.
För det finns ju också nackdelar med det.
Många av de här CSS/JS-libben har ju till exempel en performance-kostnad.
Som man kanske inte tänker på ofta för att man tänker att det är bara CSS.
Men eftersom, till exempel Site Components, nu vet jag inte om de har ändrats i de senaste versionerna,
där är det ju att allting sker i Client-side.
Så att all CSS beräknas i Client-side.
Det finns många andra libs som försöker lösa det här genom att göra det till static generation.
När du bygger din site genereras all CSS som behövs.
Och det försöker vi lösa lite.
Men som du säger så kanske man
inte behöver sträcka sig efter något verktyg. Man kan bara skriva plain CSS.
Men det blir fortfarande så här att går man tillbaka från
hela vägen från Style Component eller CSS in JS till
till vanlig CSS då tappar man ju så oerhört mycket.
Du kan inte nästla saker.
Bara det här skaver det redan för mig.
Jag kommer ihåg när vi körde det här anordnade Code in the Dark.
Just det.
Som du anordnade bland annat på jobbet.
Jag var med och tävlade.
Och man skulle skriva allting i, för det värsta, måste jag göra en style tagg?
Hur funkar det? Hur stoppar jag in CSS i markupen?
Och vart lägger jag den? Och är saker platta?
Vart ska det vara semicolon? Ska det inte vara så?
Alltså det var kaos.
För att man är som du säger så väldigt långt bort ifrån det idag på något sätt.
Och det kanske inte är något fel i sig, men det är så det är i grunden.
Det känns som att man borde ha med sig det för att kunna bygga små saker utan alla fem miljoner verktyg.
Ja, exakt. Jag tror fortfarande att även om du skriver din CSS i JavaScript eller hur du nu vill skriva den, så krävs det fortfarande en förståelse för CSS.
Kanske att du slipper vissa grejer som Cascaden eller specificiteten. Jävla svårt ord att säga det.
Eller sådana saker, att du slipper det. Men det finns så oerhört mycket i CSS som inte försvinner bara för att du skriver på ett annat sätt.
Jag tror kanske att vi pratade om det i någon tidigare avsnitt, att jag köpte en CSS-kurs för ett tag sedan.
Alltså som verkligen är en basic CSS-kurs. Och har redan lärt mig extremt mycket av den.
mycket av den. Och nu har jag inte kollat klart på alla delar som finns, men det är så spännande att jag har jobbat som webbusinvecklare i så pass många år ändå.
Eller börjar bli i alla fall. Och liksom inte hade stenkoll på hur margin collapse funkar. Och har ändå suttit och slitit med att man upptäckt en bugg som beror på det.
Och man bara "ah, varför blir det så här?"
Och så sitter man och ändrar tills det funkar istället för att ta reda på vad det faktiskt beror på.
Det här betyder att jag måste kolla upp "margin collapse" för att jag har också jobbat många år och kan inte det.
Nej, det känns som en sak som många missar att det finns över huvud taget.
Och sen blir man frustrerad av det.
Men ja, jag märkte det blir en liten skillnad i, för när jag körde CSS-modules, då handlade ju allting om klassnamn.
Så det var väldigt mycket, du skulle skapa klasser för allting, så att du kunde sätta klassnamn, så att du kunde styla specifikt den markupen som du ville styla.
Och nu när jag sitter mer med att styla i sexbilarna så har jag väl kommit på mig själv,
alltså dels att man inte kanske gör klassnamn då,
men jag orkar ju inte göra en ny komponent för att styla någonting.
Så jag har ju börjat köra väldigt mycket med "first child"
av det närmsta barnet, inte det här barnet av den här elementstypen.
Jag har börjat gå jättemycket för sådana saker istället för att jag har blivit lite lat.
Ja, antingen lat eller smidig.
Det beror på, det blir en avvägning vad som är vettigt och vad som inte.
För det kanske inte är vettigt att sätta klassnamn på exakt allting.
Jag vet att när man kör en stack-komponent,
en komponent som bara tar en sak och gör en hög av det med lite spacing emellan.
Då brukar jag använda till exempel
Not First Child och så sätter jag Margin Top, till exempel.
Gud, ja, det gör jag alltid.
Då känns det vettigt att använda de här, för man skulle ju kunna göra en mer
komplicerad lösning och sätta klasser på alla barn utom första barnet.
Men då blir det mer avancerat. Nu är det här kanske ett extremt exempel, men för att illustrera det bara.
Ja, och ibland tänker jag att jag gör mig själv en okänslig för att när jag sitter i kontextet så blir det väldigt tydligt.
Och sen går man tillbaka ett tag senare och bara "Okej, så first child that is a div and not a pie, that is not the first child of the last child".
Vad är det jag pekar på? Det blir mindre läsbart från ett annat kontext.
Jo, det känns som att det finns någon gräns där någonstans.
När man går in i ett övertool som försöker hitta var CSS kommer ifrån och det tar en kvart.
Då kanske man har dragit det lite långt.
Ja, absolut. Så gör jag inte.
Jag har ändå varit nere på typ tre nivåer eller någonting och kommit på mig själv.
Men det är jävla göttigt i stunden när det bara funkar på något sätt också.
Ja verkligen. Jag tänker också att CSS idag beroende på vilka browsers som måste stödja.
Nu dör ju IE 11 snart.
15 juni 2022.
Jag tror att det kan vara något sånt.
Då blir det lite lättare.
Men det finns ju så mycket modern CSS idag.
Som gör att det krävs väldigt mycket mindre lösningar.
Det är inte säkert att om du sträcker efter CSS i en JS för att kunna köra variabler i den.
Då behöver du inte göra det längre för det finns variabler i CSS.
Till exempel.
Sträcker du det efter bara för att göra en viss sak så finns det ofta lösningar i CSS.
Ja, så är det verkligen.
Det är kul att du sa det här med att det är med kursen och att du inte kan de grundläggande sakerna på CSS.
Det känns ju på något sätt som att vi kommer ännu längre ifrån att lära oss de grundläggande sakerna i CSS
ju mer vi trycker in den i JavaScripten.
Ja, absolut. Det håller jag med om.
Därför tycker jag att det är ganska viktigt att du kan skriva CSS med exakt samma syntax som du gör om du skriver i en CSS-fil.
Även om det blir lite syntaktiskt socker ovanpå, som att man kan nästla till exempel, så tycker jag det är vitt att du inte behöver skriva det som ett javskript objekt
där de heter lite andra saker, där det är typ Pascal case istället för kebab case eller vad det nu är i CSS.
Det var någon som sa att det var otroligt mycket lättare att använda typ logik i Ifs & Buts, inte den här stylingen, men den här stylingen i Style Components och sådana bitar.
Men jag har inte riktigt stött på det.
Det blir ju lite lättare för den kan ju generera upp olika klasser åt dig.
I och med att din CSS kan ta props.
Du kan skicka in props till din Style Components och då kan den generera upp det.
Annars skulle man inte ha det så måste man ju ha flera klasser.
Lite det här modifier som vi pratade om i BEM.
Det tänker jag kanske gör det lite lättare.
Men absolut, det finns definitivt inte så stora skillnader som folk vill få det till.
Jag undrar vart vi kommer hamna. Undrar om vi kommer röra oss ännu längre bort?
Ja, det är en väldigt bra fråga. Jag tycker det är väldigt spännande att se vad som blir nästa stora grej.
Jag tänker en grej, vi tror att vi börjar röra oss mot slutet av tiden, men en grej som jag tycker är så jävla spännande och rolig
när vi pratar CSS är ju att något som heter container queries är på G.
Det är väl liksom "approved" i working-gruppen för CSS att det kommer in i standarden.
Och det är ju då, det finns ju liksom queries idag för att typ säga,
"Okej, hur stort fönster har jag?" och därför kan man göra responsive styling.
Men här blir det istället att du kan göra, anpassa din styling efter typ
hur stor din förälder är.
Och det kommer ju att bli magiskt.
Alltså för då kan du ha komponenter som inte anpassar sig efter storleken på
fönstret utan anpassar sig efter kontexten de befinner sig i på sajten.
Ja, det är ju stort.
Så att sätter de i en smal container då kan de helt plötsligt bli avlånga.
Och har du dem i en bred container
då kan det bli ett liggande kort istället för ett stående.
Det kommer att vara så jäkla nice.
Ja, jag tror också det. Det kommer bli jävligt många breakpoint-värden att hålla reda på.
Jag tänker att det blir lättare.
För att helt plötsligt är breakpoint-värden också co-locatade till komponenten.
Ja, precis. Då blir det så här, vilket var det i den här och vilket gjorde den här?
Ja, så är det ju. Man kommer behöva hoppa runt lite mer.
Det blir inte den här globala, att vi har våra breakpoints i fönstret.
Här blir det mer att komponenterna passar sig.
Men det känns också som att det blir så mycket enklare att utveckla komponenterna.
Då kan de verkligen vara fristående.
Oavsett var man använder dem.
Speciellt för komplexa layouten.
Om fönstret är stort, då har du komponenter som kanske är mindre än om det är mellanstort.
Då ska den komponenten vara större, för det ska vara färre som får plats i en rad.
och då ska innehållet bli till sig alldeles där.
Så jag får typ rysningar att behöva tänka på och läsa det nu.
- Jag tänkte på ett exempel som jag tänkte på.
Jag håller på med ett litet hobbyprojekt nu där jag har lite drag-and-drop.
Vi kanske återkommer till det i en senare avsnitt.
Men bara då att kunna ha samma komponent som renderas
när jag drag-and-droppar till olika platser som är olika stora
och de ska visas på olika sätt.
Det skulle ju vara så sjukt nice.
- Ja.
- Medan nu blir det mer att man får rendera olika komponenter
baserat på vart i trädet de är.
Just det.
Fan, vad länge sedan jag på riktigt styla någonting från scratch.
Jag sitter ju med projekt som bygger på Material UI Googles komponentbibliotek nu.
Så det blir lite så här.
Nästan saknat det, säger jag nu.
Men om jag väl skulle sitta där och styla så skulle jag nog kanske ångra att jag någonsin sa så.
Ja, det var exakt.
Det finns så många olika sätt att göra på.
Jag tänker att det kanske får vara det för det här avsnittet.
Det får vara det.
Vill man oss något så finns vi som vanligt på Twitter.
Lämna gärna en recension i iTunes så blir vi glada.
Ja, det blir vi.
Anton blir glad. Gör honom glad allihopa.
Vi säger så och hörs om två veckor igen.
Det är jag med, hejdå! - Bye bye!
[Outromusik]
Tack för mig!
