För att kunna underlätta framtida vidareutveckling av ett system finns det några åtgärder som denna rapport har kommit fram till. För det första är det viktigt att redan vid designen av systemet skapa en arkitektur som är väl bearbetad och en struktur som är lättförståelig. Med detta följer att skapa välskrivna dokument för att beskriva dessa. Vidare är det viktigt att under själva utvecklingen skriva kod som är självbeskrivande och kommentera koden direkt under tiden utvecklingen sker. Genom att göra detta kommer man att kunna få ett ”maintai- nability index” som är lågt och påvisar på ett mätbart sätt att koden har god underhållbarhet.
A
Strukturering av CSS i React av
Albin Henriksson
En text skriven av Albin Henriksson för att ge en vägledning för utvecklare som söker efter vilka populära CSS-verktyg som finns och vilket verktyg som passar dem bäst.
A.1
Inledning
Det finns många olika sätt att strukturera CSS-kod i ett React-projekt och det finns ingen universell lösning som är bäst i alla situationer. Det finns många olika aspekter att tänka på när struktur av CSS väljs som prestanda, läsbarhet och underhållbarhet. När strukturen som skall användas i projektet väljs är det också viktigt att tänka på hur stort projektet är, vilka bibliotek som används och vilka mål det finns med koden.
A.1.1
Syfte
Syftet med denna studie är att undersöka hur olika projekt kan strukturera CSS-kod i Re- act genom att fokusera på popularitet och funktionalitet hos olika bibliotek och verktyg. Det finns ett problem att i en väldigt stor del av existerande CSS-kod är duplicerad. D. Mazina- nian et al. [36] utförde en studie på 38 webbsidor med hög trafik och fann att i snitt mer än 60% av alla CSS-deklarationer är duplicerade så de återkommer på minst ett annat ställe i koden. Ytterligare fann de att 97% av dessa dupliceringar är av ”type I” vilket innebär att de är exakta kopior av varandra. Detta visar på att det finns väldigt mycket återanvänd CSS och därför syftar denna rapport till att finnas som resurs vid valet av verktyg för CSS för att hjälpa till att bland annat reducera denna återanvändning av kod. Genom att fokusera på objektiva jämförelsebara aspekter hos de olika verktygen avser studien till att hjälpa de som har mindre erfarenhet sedan tidigare och vill undvika subjektiva åsikter vilka ofta kommer upp i diskussioner om CSS då vissa aspekter av det kan vara väldigt kontroversiella.
A.1.2
Frågeställning
Nedan nämns de frågor som rapporten avser att svara på.
1. Vilka är de populäraste alternativen för strukturering av CSS i React? 2. Hur kan dessa alternativ användas för olika projekt?
A.2. Bakgrund
3. Hur kan olika CSS-in-JS-bibliotek användas för olika projekt?
A.2
Bakgrund
CSS är ett verktyg som har använts inom webbutveckling sedan Internet Explorer 3 kom ut år 1996 och det finns väldigt många bibliotek som underlättar användandet av CSS [37]. Det finns därför många olika strategier för att strukturera CSS-kod i React, och i detta projeket har gruppen valt biblioteket Styled Components.
A.3
Teori
I detta avsnitt beskrivs viktiga termer som används i rapporten.
A.3.1
CSS
CSS (cascading style sheets) är ett programspråk som används för att ge stil till komponenter genom att ändra till exempel typsnitt, storlek, marginaler och färger [38].
A.3.2
Javascript
Javascript, förkortat JS, är ett programspråk som används för att skapa funktionalitet i webb- sidor och det används väldigt ofta tillsammans med CSS och HTML.
A.3.3
CSS-in-JS
CSS-in-JS är en en variant av CSS som kommit till på senare år. Biblioteken som följer den- na struktur använder sig av funktioner i JS för att designa komponenter. Anledningen till att denna idé har vuxit fram är att lösa problemet med krockar i klassnamnm och svaga kopplingar mellan CSS-klasser och JS-kod. Denna svaga koppling kan leda till att ”död kod” uppstår. Eftersom det är väldigt svårt att veta var en viss klass används i koden så kan det också vara lätt att utvecklare missar att en klass inte används överhuvudtaget och då kallas den klassen för ”död kod”.
A.4
Metod
Metoden som har använts för att samla in datan är analys av enkäter från 2020.stateofcss.com där utvecklare har svarat på frågor om om hur de har använt CSS under året 2020. Specifikt har rankning av ”Pre-/Post-processors” och ranking av ”CSS-in-JS” använts där de svarande fick svara mellan ”would use again”, ”would not use again”, ”want to learn”, ”not interested” eller ”never heard” om olika CSS-bibliotek. För att verifiera de slutsatser som dragits från resultatet i enkäten användes npmjs.com för att få data på hur ofta bibliotek laddas ned och används. Genom att se hur de olika utvecklarna svarat och studera nedladdningssifror kunde de relevanta alternativen till frågeställning 1 hittas på ett objektivt sätt. Eftersom enkäten inte fokuserar specifikt på React har en studie av blogginlägg utförts för att finna de React- specifika alternativ som finns. Nedan beskrivs hur olika metriker beräknas i enkäten för att lättare kunna jämföra olika bibliotek.
• Satisfication = would use again / (would use again + would not use again) • Interest = want to learn / (want to learn + not interested)
• Usage = (would use again + would not use again) / total • Awareness = (total - never heard) / total [39]
A.5. Resultat
För att finna svaret till frågeställning 2 och 3 gjordes en litteraturstudie från de separata bib- liotekens hemsidor för att finna skillnader mellan funktioner hos de olika alternativen.
A.5
Resultat
I detta avsnitt presenteras resultaten av litteraturstudien och resultatet av enkäten.
A.5.1
Vanilla CSS i React
Vanilla CSS syftar på CSS utan tillagda bibliotek och i React finns det ett antal sätt att hantera CSS utan extra bibliotek. Det första och enklaste alternativet är Inline Styling där CSS till en viss komponent skrivs direkt vid komponenten. Detta medför ett stort problem i att det inte finns något sätt att återanvända CSS-kod om detta alternativ används. Dessutom krävs det aningen förändrad syntax för att använda detta alternativ. Det är dock väldigt enkelt och snabbt att använda eftersom det inte krävs någon koppling mellan klasser eller extra filer. Ett annat alternativ är CSS-klasser i separata .CSS-filer. Detta är det vanligaste sättet att använda CSS och är det sättet som de flesta tänker på när de hör CSS. Detta gör att det går att återanvända en viss del kod genom att använda samma klassnamn i olika komponenter men det medför också ett problem med att klassnamn kan krocka och på så sätt skapa oönskade effekter då komponenter råkar ha samma klassnamn som andra komponenter. CSS modules löser ovanstående problem genom att en komponentfil importerar en viss CSS-fil och därmed begränsar komponentens klasser till de klasser som finns i den CSS-filen .[40]
A.5.2
Resultat från enkät
Figur A.1: Andelen utvecklare i studien som använt respektive bibliotek. [39] Från figur A.1 går det att se att Styled Components utan tvekan är det vanligaste före- kommande CSS-in-JS-biblioteket enligt enkäten eftersom det gick från 40% användning 2019 till 52% användning 2020. Det går även att se att alla de tre CSS-in-JS-bibliotek som nämns i denna rapport har ökat både i användning och intresse hos utvecklarna från 2019 till 2020 samtidigt som många fler bibliotek har vuxit till att bli tillräckligt stora för att komma upp som svar i enkäten (se figur A.2). Både Emotion och JSS har dubblat andelen utvecklare som använder sig av de biblioteken vilket visar på att det finns stor nytta för dessa bibliotek också.
A.5. Resultat
Figur A.2: Intresse i biblioteken från utvecklare i studien. [39]
Detta reflekteras dock inte helt i dess nedladdningssiffror från npmjs.com där Styled Com- ponents har ca 2,3M nedladdningar per vecka Emotion har ca 3,9M [41] och JSS ligger runt 2,3M nedladdningar per vecka [42]. Däremot verkar antalet beroende bibliotek matcha de resultat som enkäten givit där Styled Components har 13 378, Emotion har 3 204 och JSS har 697 bibliotek.[43]
A.5.3
Jämförelse mellan Styled Components och Sass
Trots att Styled Components enligt enkäten verkar vara det vanligaste förekommande CSS-in- JS-biblioteket används det fortfarande mycket mindre än Sass vilket är det absolut vanligaste generella verktyget för CSS enligt enkäten [44]. Sass har haft en 100% medvetenhet hos de utvecklare som blivit tillfrågade både år 2019 och 2020. Andelen som använt sig av det har även ökat från 86% till 89% från 2019 till 2020. Dock, värt att notera är att den inte ökat lika mycket som vare sig Styled Components, JSS eller Emotion. Trots Sass ökning i användare har tillfredsställelse minskat från 2019 till 2020.
A.5.4
Skillnad i funktionalitet bland CSS-in-JS-bibliotek
Det finns egentligen inte så många stora skillnader mellan hur de olika CSS-in-JS-biblioteken används. En skillnad är dock att Emotions syntax är väldigt unik och enligt vissa aningen motsägelsefull eftersom all stil för komponenten skrivs efter className-fältet som normalt sett tar in en sträng med namnet på CSS-klassen (se figur A.3).
Detta går dock att ändra på genom att använda @emotion/styled-tillägget vilket ändrar syntaxen till en syntax som är i princip identisk till den som används i Styled Components ( se figur A.4) och faktum är att Emotion nämner Styled Components som en av deras inspira- tionskällor [41]. En funktion hos Emotion som är bättre än Styled Components är att det finns source maps vilket är en funktion som hjälper till vid debuggning. Eftersom det finns source maps så går det i debuggningsverktyget se exakt var i koden en specifik CSS-klass kommer ifrån till skillnad från Styled Components där det inte finns någon sådan information.
A.6. Diskussion
Figur A.3: Standard syntax för Emotion inspirerad av kodexempel på bibliotekets hemsida. [45]
Figur A.4: Syntax i Emotion med @emotion/styled biblioteket inspirerad av kodexempel på bibliotekets hemsida. [45]
A.6
Diskussion
Nedan diskuteras resultatet från studien för att kunna dra slutsatser om frågeställningarna som ställts.
A.6.1
Styled Components i detta projekt
I detta projekt har biblioteket Material-UI använts vilket som tidigare nämnt använder sig av JSS internt. Trots detta valdes Styled Components på grund av dess populäritet. Material-UI har hjälpartiklar på sin hemsida som har hjälpt vid kombinationen av de två biblioteken och därför har det upplevts smidigt att använda Styled Components trots att Material-UI använts [46]. Men trots att det fungerat rätt bra hade det förmodligen gått att spara utvecklingstid ge- nom att använda den JSS-baserade lösningen som Material-UI har inbyggd eftersom det hade krävts mycket mindre omskrivning av kod när exempelkod har hämtas från sin hemsida.