32. Ett bibliotek med komponenter
lyssna! 
I dagens avsnitt snackar vi om komponentbibliotek. Vad det är för något, hur vi använder dem, vilka komponenter vill vi ha i ett bibliotek och mycket annat. Anton har en förkärlek för komponentbibliotek som är “headless” där det inte följer med någon styling vilket leder in på diskussioner om när man faktiskt vill att stylingen ska följa med, avvägningen mellan att hålla komponenter små och att tillhandahålla alla användningsfall som behövs, samt hur den avvägningen förändras beroende på vem användaren är.
Dessutom en hel del om Atomic Design, att hitta ett gemensamt språk, koda först och tänka sen samt såklart en liten liten parantes om TypeScript.
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:
Vad kallar programmeraren ett misslyckat bankrån?
En cache-miss.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Dagens skämt, inspirationen kommer från vår lyssnare Erik men jag har gjort om det lite lite grann.
Vad kallar programmeraren ett misslyckat bankrån?
Ingen aning.
En cash miss.
Ja, absolut, absolut. Bra jobbat Erik.
Tack Erik.
För att du också fick förklara för mig vad en cash miss är. Men jag lärde mig något nytt.
Ja, men det är ju toppen ändå. Det är ändå alltid något som man säger.
Verkligen. Förfrågar vi inte vad det betyder bara.
Nej, det ska vi absolut inte göra. Det lämnar vi till ett annat avsnitt så kan vi bara gå in på det.
på det. Välkommen till ett nytt avsnitt av ASTF.
Idag kommer jag i alla fall ihåg att säga välkomna till avsnittet, vilket känns bra.
Det glömde jag ju lite förra gången när det var lite exalterat om något ämne.
Vem vet vad det var. Hur mår du i värmen, Therese?
Jag är på toppen. Nej, det är väldigt varmt.
Så jag känner mig lite extra långsam.
Hur mår du?
Det är så fruktansvärt varmt.
Det har varit ett lite återkommande inslag i det här.
När vi spelar in så brukar vi bygga en liten studie och hänga upp lakan och grejer.
Men idag så gick det absolut inte att göra det där.
För det är så sinnessjukt varmt.
Så nu sitter jag bara med lite kuddar runt omkring mig och lite allt möjligt.
Ljudkvaliteten kanske inte på topp, men det får man stå ut med eftersom det är sommar och varmt.
- Jag har stängt min balkongdörr på första gången på, jag vet inte hur länge.
Det märks, jag känner det så att säga.
- Ja, jag kan verkligen tänka mig det.
Så avsnittet kanske är lite långsammare än vanligt, men det vi tänkte prata om är väl lite så här
med typ komponentbibliotek eller designsystem.
Det finns ju så jävla många termer och jag har fan inte facit på vad alla betyder.
Men typ ett komponentbibliotek var väl utgångspunkten.
Och jag kom att tänka på det här för att jag satt med ett litet HAL-projekt för ett tag sedan.
Fick äntligen lite inspiration igen efter allt flyttande och bytt uppdrag och allt möjligt.
Men så satt jag med det och drog in ett komponentbibliotek som heter Radix, eller Radix UI.
Som är...
De har både ett komponentbibliotek, men det var också något som de kallade för primitives.
Vilket är typ...
Ostylade, eller headless.
Det vill säga, du får bara massa komponenter och sen får du styla dem själv.
Och annars har de bara default styling.
Och sen har de väldigt bra stöd för accessibility, eller tillgänglighet.
Och allt annat man egentligen vill ha funktionsmässigt.
Men just stylingen får man göra helt själv.
Då kom jag på att det här kan jag prata med Therese om och se vad du tycker.
För vi har ju varit in på det lite tidigare att du har suttit med material UI.
Är det du har suttit med?
– Ja, på olika ställen faktiskt.
Jag har suttit just nu väldigt mycket med material UI.
Men har även suttit en del på projekt där man valt att bygga egna komponentbibliotek.
Så att en hel del sådana har det ändå blivit.
Jag har aldrig hört talas om RADx.
- Nej det känns som att det är ganska nytt faktiskt.
Alltså de har liksom så här, det finns inte alla komponenter och de utvecklar nya grejer hela tiden och sånt där.
Men jag tycker det verkar riktigt, riktigt nice.
Och jag vet inte om vi ska definiera komponentbibliotek.
Det känns som att man kan dela in en massa olika saker i det.
För mig är komponentbibliotek bara en samling med färdigbyggda komponenter.
I varierande grad kanske.
Som jag var inne på tidigare med de här Headless, där man designar dem själva.
Men bara en samling komponenter som man kan återanvända och som gör sin lilla grej väldigt bra.
Sen finns det ju en massa andra designsystem som jag nämnde tidigare.
Det är väl kanske mer när man drar in även färger och vilka typsnitt man ska ha och
allting sånt och applicerar det på komponenterna så att säga.
Ja, för jag kan ju ha det helt runt om bakfoten.
Men just som du säger designsystem tänker jag är allt som ligger runt omkring.
Där skulle jag även kanske kunna stoppa in
grid-system och även vilka breakpoints man vill jobba med för de olika skärmstorlekarna och så vidare.
Så att det verkligen är en komponent.
Och här tänker jag att man också ofta kan komma in på atomic design.
Att en komponent ofta är väldigt små saker.
Det börjar med, nu känns som jag har nämnt mycket saker, så först atomic design då.
Det är ett designsystem som är av en person och jag kommer inte ihåg hans namn nu.
- Men det kommer säkert att påverka sen. - Kan det vara "bread frost" kanske?
- Ja, det kan det nog vara, ja. Just det.
Men i alla fall att det är hur du bygger upp sidor, att du har atomer som är de minsta beståndsdelarna vi kan ha,
och med hjälp av dem så bygger du ihop molekyler, precis som det funkar i kemin, och all materia som vi har.
Sen kan du använda det av atomer och molekyler för att bygga organismer.
Och sen kan du använda dem för att bygga helasidor.
Så det är verkligen att bryta ner det till de minsta möjliga beståndsdelarna och göra dem återanvändbara.
Så att en atom är till exempel kanske en knapp.
Och den knappen kan du ta och stoppa in var du behöver den.
Men den knappen kommer alltid vara en komponent du kan använda en atom.
Och den ser alltid ut på samma sätt.
Eller den fungerar på samma sätt.
och sen kan du välja hur den ska se ut.
Jag babblar.
- Nej, men det är så att jag också stött på atomic design lite grann.
Jag tycker det är ett ganska vettigt sätt att tänka på för att det blir väldigt tydligt
så att det blir tydligt hur komponenterna eller hur de olika strukturerna ska interagera med varandra.
Sen tycker jag alltid att det blir svårt att säga, okej, men vad är en atom?
Och vad ska vara en molekyl, till exempel?
och när blir det en organism och så vidare.
Så på så sätt tycker jag att det kan vara lite småklurigt ibland.
Men när det är gjort bra så tycker jag att det funkar väldigt, väldigt bra.
Och det är ett sätt att tänka och prata om sina komponenter på ett sätt som inte är
bara "det här är en knapp", "det här är en text".
– Ja, precis. Men just också att när man pratar om komponentbibliotek
då hoppar jag ofta till just den här typen, alltså atomic design i huvudet,
och jag ser det ofta som att ett komponentbibliotek för mig brukar ofta dra gränser i just atomer och molekyler,
men egentligen inte så mycket mer.
För att jag tycker att ett komponentbibliotek är som allra bäst när det är simpelt,
eller så simpelt som det går att göra det,
När man börjar bygga väldigt komplexa saker så får de ofta väldigt mycket edge case.
Du vill tillgodose dom edge casen och sen bygger du på det och så blir det mer komplexitet.
Och sen så om någon går in och råddar och ändrar den då kan du förstöra saker på många andra ställen.
Så jag tycker det är svårt att skapa bibliotek som innehåller jättemycket komplexitet.
Ja, verkligen. Det är verkligen en gränsdragning. Vad ska ingå i komponentbiblioteket?
Jag tycker att Radix, som jag nämnde tidigare, där har jag egentligen bara använt deras primitives.
Där är det verkligen grundläggande saker.
Sedan har de ett extremt stort fokus på just tillgänglighet.
Vilket gör att de har typ såhär, ja men, Radio Group.
Som är en grupp med radio-knappar som verkligen har bra stöd både för att bli stylade.
För att radio-knappar är ganska notoriskt svåra att styla.
Man måste ju hålla på med en massa ful saker.
Men de har både bra stöd för att styla dem och då bra stöd för att det fortfarande stöds av alla guidelines för att tillgängligheten ska vara bra.
Det är en grundläggande grej som finns.
Sen finns det lika mycket, om vi tar några mer exempel, typ en drop-down-meny.
Det är definitivt ett steg upp, men jag tycker fortfarande att det passar in.
Det är fortfarande väldigt komponentbaserat. Det är en komponent och så drar du in fler komponenter i den för att bygga ut den här menyn.
Och då tycker jag också att det ändå passar in i ett komponentbibliotek, även om det är på gränsen till att det är mycket mer interaktivitet och lite mer komplicerad komponent.
- Ja, jag har lite... för att hur mycket... jag antar att du bygger all logik själv, eller vad man ska kalla det.
- Nej... - Vad du vill ska hända när man klickar på menyn och sånt, eller får du en...
- Nej, alltså det beror lite... - ...skickar du in det?
- Ja, exakt. Om vi tar fallet, liksom drop-down-menyn, då är det liksom att du har en komponent som är en root-komponent
I den skickar du in en trigger som är själva knappen som ska trigga det här.
Sen skickar du också in en som är själva menyroten.
Alltså det som ska visas.
Och i den innehåller varje rad i den här dropdown-menyn.
I och med att det är helt ostajlat så får man ju stajla allting själv.
Men det är fortfarande de elementen man förväntar sig att det ska vara.
Och sen att du får även med att du kan styra det med tangentbord och att det blir rätt saker som sägs när du kör skärmläsare.
Så all den logiken finns ju där.
Sen såklart att vad som ska hända när du klickar på en specifik val i menyn, det måste man ju kanske styra själv.
Men som standard så har de att det är en komponent som heter "dropdownmenu.trigger"
Och den kommer att rendera en knapp för dig som öppnar menyn.
Sen kan man såklart köra, för de här komponenterna är "uncontrolled"
Som är på samma sätt som du kan köra med formulär till exempel.
Men du kan också skicka in en "open state" eller "open bool"
Som säger att "nu vill jag styra om den här ska vara öppen eller stängd"
Så att du kan göra lite som du vill.
av standard så skulle jag säga att de rekommenderar att man kör
dem "uncontrolled" för att då blir det verkligen rätt med skärmläsare och allt annat sånt runt omkring.
Det är jäkligt nice att få med det här med accessibility, bra accessibility
för det är jäkla lätt att trampa bort från stigen i den djungen.
Ja verkligen.
Och även om man bara tittar på den här radioknapparna.
De är så här, ja det kanske är lite enklare.
Men sen ska man börja styla dem själva.
Så blir det så här, man måste göra några workarounds för att man inte kan styla radioknappar.
Blablabla.
Och då blir det rätt liksom.
Men samtidigt också de här mer komplexa komponenterna.
Som till exempel en dropdown.
Att den, eller bara så här okej men jag vet att den här kommer funka om jag kör med tangentbord eller om jag kör med en skärmläsare eller vad det nu kan vara.
Så att på så sätt är det ju sjukt skönt att använda det.
Och sen älskar jag ju att det är helt ostylat.
För att det känns också som en grej som har kommit mycket på sistone.
Att förr var det väldigt mycket, liksom...
Att komponentbibliotekar kom med sin egen styling och sen fick man skriva över den.
Och så blev det ofta lite konflikter.
Man bara "Åh nej, nu har det blivit så här, här och jag vet inte vart jag är riktigt."
Medans nu för tiden tror jag att fler och fler erbjuder att det är "headless".
Det vill säga att du har inget utseende som bandlas med dem.
Jag kan tänka mig att det är väldigt nice att man får styla det själv.
Jag kommer ihåg det när man kollar på CSS bootstrap.
När det här kom så såg man verkligen att det här är en bootstrap app.
Den har dragit in bootstrap CSS för att alla såg exakt likadana ut.
Du kunde välja färg, men utseendena var fortfarande de samma.
Det tänker jag att man vill bortifrån.
Men därmed känns det som att man fastnar lite för den grejen, just om man kör material UI.
För det finns ju såklart möjlighet att styla om det, men det är ju väldigt ändå...
Alltså det ser ju ut på ett visst sätt ändå, speciellt om man inte stylar om det på vägen så har den ju verkligen en stil som man känner igen om man har suttit med det i taget. Eller sa jag bara suttit alldeles för mycket med det? Jag vet inte.
Och det är ju väldigt schysst om man till exempel vill ha ett hobbyprojekt, vill ha upp det fort eller man bryr sig inte om styling eller kanske till och med om det är interna projekt och sånt.
Men om det är extern webb så finner jag det ändå lite knöligt liksom. För då blir jag mer så här, men om man vill ha ett speciellt utseende och Car faktiskt har i Trumman en hel design, ett designsystem för man vill att saker ska se ut.
Då känns det så himla svårt att ta in existerande saker som Material.UI och sedan verkligen lägga tid på att forma om dem.
Då tänker jag att det är bättre att göra det från början.
Nu har jag inte varit i en sån här situation, men jag skulle gärna inte vilja hamna i en sån heller.
- Ja, precis.
För att gå in på det här lite grann.
Det var ju en period när det kändes som att alla nya hemsidor som gjordes såg ut som bootstrap.
Det var verkligen standardutseende från BoosterShop.
Sen lade de till att man kunde ändra lite färger, så var det folk som gjorde det.
Men jag håller verkligen med dig om att det användningsområde finns fortfarande kvar.
När man verkligen säger att det är en intern grej, vi bryr oss inte hur det ser ut.
Eller det är ett litet hobbyprojekt.
Jag vill inte hålla på och styla, utan jag vill kanske testa att bygga en backend.
Då vill jag bara slänga upp en snabb frontend, eller vad det nu kan vara.
Då finns det definitivt fortfarande nytta av de här färdigstylade biblioteken.
Absolut. Eller också att det här är ett jättestort komplext system som har mycket mer fokus på funktionen på utseende.
Ja, exakt. Och då vet man ju också att man får saker som är väl testade helt enkelt.
I och med att så många använder dem.
Och då kan man också vara säker på att vi inte kommer få några konstiga visuella buggar om vi kör det här rakt upp och ner.
Nej. Men ibland så blir jag ändå lite fundersam på, eller fundersam på, men jag tycker ibland att det känns så blåtat eller vad man ska kalla det, eller stort, när man drar in en hyfsat liten komponent, kanske till och med hyfsat simpel komponent, men som man vet i bakgrunden är enorm för att kunna täcka alla specialfall och alla extra lösningar och du kan skicka in,
Du har ett enormt API för att skicka in olika proppar om man snackar React-komponenter för att du ska kunna tillgodose alla möjliga scenarion eftersom du är ett publikt komponentbibliotek.
Då blir det så här, när blir det snarare svårare att jobba med beroende på vad du har för egen,
vad du vill uppfylla med dina komponenter på det du bygger?
Var tänker man att den gränsen är?
Finns det en gräns där det blir jobbigare?
- Ja, det är ju definitivt en bra fråga för att det känns ju verkligen lite samma sak som,
alltså det handlar ju oavsett vad man bygger nästan, att man bara bygger på saker
och bygger på saker och bygger på saker och till slut så är det så här, oj nu är det ingen som har tänkt på helheten här
att det blir supersvårt att använda.
Jag vet, det var något bibliotek jag använde som hette typ AG Grid tror jag.
Och API-ytan på den var så oerhört stor.
Det var verkligen en komponent som hette AG Grid som man drog in för alla möjliga användningsområden som fanns.
Det spelar ingen roll vad för typ av tabell eller något sånt skulle det vara.
Det var verkligen typ Excel i webbläsaren.
Och du kunde använda den för allt.
Det fanns hur många proppar som helst.
De flesta proppar var att du skickade in ett optionsobjekt som var hur stort som helst.
Det var så sjukt mycket grejer.
Och där kände jag att där har man misslyckats lite grann.
Det måste vara vettigare att bryta ut det.
"Okej, men vi har separata komponenter för vissa saker som gör vissa grejer väldigt bra."
Men det här att man inte behöver fundera på.
"Okej, behöver jag använda en av de här 150 propparna nu bara för att göra den här grejen jag vill?"
Och vilka proppar är kompatibla med varann och allting sånt.
Så att...
Nej, det måste verkligen vara att man får hålla tillbaka om man gör något externt.
Eller liksom publikt, kanske man ska säga.
Som ska användas av många.
För det gäller att den här komponenten ska bara göra det här.
Om det kommer en person som vill ha till use case så kanske de kan bygga det själva.
Det gäller att man vänder på kontrollen av komponenten.
Det finns många sådana sätt.
Vi kommer ihåg när vi pratade om det tidigare, men det finns render props eller hooks nu för tiden.
Eller higher order components förut till exempel.
Som gör att du kan ge användaren av komponenten mer kontroll över vad den gör.
utan att på det viset lägga till en till prop som gör det du ska göra.
Så jag tror också att precis som du säger, till slut så blir det kanske lite mer för svåranvänt för att det kanske ska vara värt det.
Men det beror ju såklart också på kvaliteten på komponenterna.
- Ja, men just också ibland att vara hur mycket kod drar du in egentligen för att göra en liten sak om du inte tar tillvara på alla de här superkomplexa sakerna dessutom.
- Ja, men verkligen. Det är ju definitivt en ganska svår avvägning tror jag. Jag har inte slutat gjort det här själv någon gång.
Men det känns ändå som att det är en väldigt svår avvägning.
Och särskilt, jag tror att det kanske är en ännu svårare avvägning
om man sitter internt på ett bolag.
Alltså om du sitter på ett större bolag så ska du utveckla deras komponentbibliotek
och så kommer det en massa folk från olika ställen
och vill använda det här och har lite olika krav på alla.
Och då blir det helt plötsligt liksom så här
då är det inte någon random på internet som säger åt dig att göra det här.
Utan då är det istället, okej det är någon i bolaget som har ett krav som behöver det här
och det kommer ge oss värde, men hur ska vi hantera det?
- Ja, för det där är jag lite svår också, för jag tycker det är en så otrolig skillnad på något sätt att bygga komponenter i ett komponentbibliotek.
Man måste verkligen tänka, alltså jag kan ju ofta känna mig väldigt så här, okej, men jag ska bygga det här, jag ska lösa det här problemet, det ska se ut så där.
Och då sätter jag mig ner och sen så börjar jag bygga på ett sätt som kanske inte alltid är så generiskt från början, utan verkligen är gjort för att vara i det kontextet jag tänkte använda det i.
Men när man bygger ett komponent i ett komponentbibliotek så är det snarare så att du ska kunna se, okej, vart skulle det här eventuellt kunna användas?
Hur ser till att den kan vara helt isolerande och fungerande av sig själv? Hur hanterar jag eventuella edge cases?
Edge Cases. Man måste verkligen hitta alla eventualiteter innan den på något sätt har börjat användas.
Och det är jättesvårt.
Ja, verkligen. Man måste välja, ska vi bygga för att komponenten ska vara så flexibel som möjligt?
"Nu förutspår vi att det här use caset kommer komma så vi ska bygga den här komponenten så flexibla att den klarar av det."
Eller bygger man först och främst "Okej, vi har det här use caset. Om vi bygger det nu, då funkar komponenten åt nu."
Men sen om det kommer till use case, då måste vi bygga och lägga på det ytterligare.
Ja, och då kanske man verkligen använder en funktion som man verkligen gjort innan.
Då måste man börja typ versionshantera eller lägga till flera olika proppar.
Sen måste man deprecate den.
Sen helt plötsligt så sitter man verkligen i smeten, så att säga.
Eller vad man ska säga.
Ja, nämen exakt.
Och det här är ju liksom också i och för sig,
alltså det är ju inte ett annorlunda problem mot när man bygger komponenter i en app
utan att tänka att det är ett komponentbibliotek.
Alltså det är liknande fråga man ställer sig,
även om det kanske är på en mindre skala när man bygger bara lokalt.
– Ja, det beror ju på hur bråttom man har, tänkte jag säga.
– Ja, det är i och för sig alltid en bra brasklapp att lägga in.
"Okej, det beror lite på hur bråttom det är."
– Ja, för ibland så kanske man... eller kanske man och man...
Jag kanske till exempel bara bygger någonting som jag vet är extremt till skräddarsytt i just den situationen som jag bygger det till.
Till exempel att stylingen kanske har en massa extra, om vi nu ska säga att man har styling också, kanske har en massa extra whitespaces som man absolut inte vill ha om det skulle vara en jinglerisk komponent.
komponent för det kommer en paja massa andra grejer och man kanske inte gör det super flexibel.
Det kanske inte är att bara lyfta ur den komponenten ibland.
Alltså det finns ju ganska många sådana genvägar som jag tar speciellt när jag har bråttom som man absolut inte kan göra i ett
komponentbibliotek liksom.
Så det är därför jag känner att det blir, jag är väl kanske en sån som kodar före och tänker sen, men i ett komponentbibliotek så måste man
verkligen tänka först.
Ja.
Nej, men absolut. Så är det ju verkligen. Där har du helt rätt i.
Det är nog relativt stora skillnader ändå.
Även om man kanske tänker samma banor när man har tid.
Men jag tänker också, ur ett användarperspektiv,
så tycker jag också att det är så här extremt skönt när det är så tydliga komponenter.
Jag har varit med några gånger, om man har vissa komponenter i ett bibliotek som man tar upp och så vet man inte riktigt vilken man ska använda till vad.
De har ungefär samma use case, men de har liksom splittats på dem.
Det kanske har varit en komponent som de har splittat på för att nu ska den användas på lite olika sätt.
Men att de är nästan lite för nära varandra.
Då blir det istället åt andra hållet att jag försöker använda den här och bara "Okej, vilken ska jag använda?"
Jag kommer inte ihåg om det var någon bibliotek eller om det bara var någon fristående komponent som någon hade släppt.
Men det är liksom att man skulle använda en och så fanns det två.
Och så började man bygga en för det såg rätt ut.
Och så kom en halvverk som bara "Nu funkar inte det där" och så googlade man lite grann.
"Ja, men använd den andra" fast det stod liksom ingenstans.
Eller det förklarades inte riktigt bra och så blev man bara irriterad istället.
Och det är också en grej som kanske kommer med att om biblioteket blir för stort eller att man splittar det för mycket
och då är det istället ett problem åt andra hållet jämfört med att man har en komponent som är skitstor.
Ja, och om man inte har en tydlig, lättläst dokumentation så kan det ju verkligen vara döden.
Ja, dokumentationen känns ju superviktig.
Just för att där kan man både förklara hur det är tänkt att användas, men även vilka proppar som finns och hur det ska fungera.
Och det är också för att cirkla tillbaka till något tidigare som vi har sagt, komponensbibliotek utan typescript.
Det skulle jag kanske inte använda idag.
Det är fan det bästa. Autosjälvdokumenterande, det är en riktig dröm.
Men är allt bara självdokumentation? Är allting så självklart när man bara läser saker? Jag gråter ju ofta inombords på jobbet när jag läser dokumentation eller typescripttyper för att jag förstår ingenting.
sen så känner jag mig jättetrög.
- Ja, vissa TypeScript-typer kan man verkligen riva sitt hår över.
Men jag tänker att oftast är det väldigt skönt att bara kunna se att
okej, det här är de propparna som finns. De förväntar sig det här.
Det syns direkt i VS Code och inga konstigheter.
- Ja, som jag har sagt i tidigare avsnitt, jag förstår helt klart poängen med det.
mitt inre barn fortfarande lite grinig.
- Jag kanske ska sluta ta upp typeskriften och förstöra stämningen.
- Jag orkar inte ens vara upprörd i den här värmen.
- Det är det jag ska passa på.
- Hur generiska är de här biblioteken?
De kan väl inte vara det, tänker jag. Och då säger jag det som kanske är lite nöjvt, men jag har ju befunnit min React-världen väldigt, väldigt länge.
Så jag har ju egentligen inte stött på komponentbibliotek i andra ramverk. Har du jobbat med det?
- Nej, när du säger det nu så tror jag inte det. Eller undrar om jag kanske använde något när jag satt i Vue för massa år sedan.
Men inget som jag kan referera till direkt.
- Vi blir ju lite nischade sådär va? Båda React-nerds.
- Det är ju verkligen lätt hänt.
Det kanske vi kan prata om i ett avsnitt och vara generalist eller specialist.
- Ja, det kan vi absolut göra.
- Jag tänker att det här avsnittet börjar dra sig mot sitt slut.
utan att ha stenkoll på tiden, men jag tror att vi är uppe i vår vanliga tid ungefär.
Har du något mer kul att tillägga om komponentbibliotek i ditt liv?
Nej, jag tänker att vi kan bara avsluta på att vi vet ingenting om det utanför React-världen
och så får vi återkomma helt enkelt.
Om någon har jämförelser så är det superintressant.
Om man har upplevt att det är superstora skillnader mellan View och Reacts komponentbibliotek
eller ännu längre ifrån varandra, även om det inte är View och React utan React och P&P.
Skicka gärna något till oss och berätta hur mycket som skiljer sig.
Med det sagt tackar vi för den här gången och hoppas att ni inte har det lika varmt som oss.
Vi finns som vanligt på Twitter, länkarna ligger i beskrivningen.
Och med det så säger vi hej då för den här gången!
- Hejdå! - Bye bye!
[Outromusik]
