Vilka fördelar och nackdelar har Gitflow jämfört med andra metoder

såsom Oneflow och Centralized workflow?

Den största fördelen med Gitflow är att strategin tillåter merge requests. Vidare bidrar kor- rekt användning av Gitflow till att det alltid finns en version av projektet som är stabil nog för att publiceras. Denna version ska alltid finnas i master. Samtidigt som det finns en stabil version kan utveckling bedrivas i utvecklingsgrenen. Centralized workflow tillåter inte mer- ge request, men å andra sidan kan denna strategi med enkelhet användas av personer utan mycket kunskap om Git och samtidigt skapa en väldigt lättläslig historik vilket också är för- delaktigt för nya användare. Oneflow tillåter precis som Gitflow merge requests. Skillnaden är att denna bara har en gren för utveckling. Tillsammans med användning av taggar i Git kan man märka versioner som är färdiga för publicering och sedan fortsätta utvecklingen som vanligt.

D

Tillståndsstrukturer för

webbapplikationer av Björn

Möller Ehrnlund

D.1

Inledning

Webbapplikationer är en växande trend hos både företagsprojekt och hobbyprojekt. Med en- dast en implementation kan applikationer köras på enheter som har tillgång till webbläsare. När applikationerna blir större och hanterar mer data blir det svårare att implementera och förstå dem, speciellt för de utvecklare som är mindre insatta i webbutveckling. Denna studie ska därmed presentera och jämföra biblioteken Unstated och Redux som båda är utvecklade för att dela data mellan komponenter i webbapplikationer. Biblioteken kommer att anvnän- das med ramverket React i två implementationer av en mindre webbapplikation som desig- nades för att testa de olika funktionaliteterna hos biblioteken. Detta ska ge en inblick i om en utvecklare behöver använda ett bibliotek för tillståndshantering och vilket den i så fall ska använda.

D.1.1

Syfte

Syftet med denna studie är att jämföra fördelar och nackdelar med olika implementationer av tillståndsstrukturer för webbapplikationer. Huvudsakligt fokus kommer att ligga på hur lång tid det tar att lära sig grunderna hos de studerade biblioteken och hur de påverkar applikationers komponenter.

D.1.2

Frågeställningar

För att studera biblioteken kommer följande frågeställningar att användas:

1. Hur lång tid tar det att sätta sig in i grunderna bakom Unstated och Redux och imple- mentera en given webbapplikation i dem?

2. Hur påverkas komponenternas moduläritet av de olika biblioteken?

D.1.3

Bakgrund

I projektet som utförts i detta arbete hade projektmedlemmarna ingen tidigare erfarenhet av att arbeta med React. Därmed blev det en svårighet att besluta om vilken typ av tillståndshan-

D.2. Teori

tering som skulle användas för applikationen. Därför utfördes denna studie för att undersöka fördelar och nackdelar som kommer med olika lösningar för tillståndshantering i React.

D.2

Teori

D.2.1

Google Chrome

Google Chrome är en webbläsare som är utvecklad av Google. Webbläsaren är kostnadsfri och stödjs av de flesta moderna datorer. Webbläsaren har dels användas i vardagligt syfte men också för djupare testning och felsökning av webbsidor genom dess inspektionsverktyg. Verktyget tillåter bland annat visualisering av applikationens loggningsmeddelanden och möjlighet för modifikation av element. [36]

D.2.2

Model-View-Controller

Model-View-Controller (MVC) är ett designmönster för webbapplikationer. Mönstret intro- ducerades redan på 70-talet och är idag en vanligt förekommande struktur hos webbapplika- tioner.

Strukturen bygger på att applikationen delas upp i komponenterna Model, View och Con- troller. Model är den del av applikationen som innehåller logiken för att hämta och uppdatera datan. Controller innehåller abstraktioner som abstraherar och möjliggör modifiering av da- tan hos Model. View definierar hur applikationen ska visualiseras för användaren och hur användarens interaktioner ska påverka applikationens data. [68]

D.2.3

Tillståndshantering i React

React är ett ramverk för webbapplikationer, se avsnitt 2.1.5. För att hantera tillstånd i React kan klassen React.Component ärvas. Detta ger bland annat tillgång till variabeln state och funk- tionen setState. I den skapade klassen kan då ett initialt tillstånd definieras genom att ansätta state i dess konstruktor. För att sedan uppdatera dess state samt uppdatera komponentens utseende används funktionen setState.

För att dela data mellan komponenter krävs data i en överliggande komponent då kom- ponenter endast känner till sina direkt underliggande komponenter. Datan skickas till de underliggande komponenterna vid dess initialiseringar. För att modifiera datan från en un- derliggande komponent behöver en funktion definieras i den överliggande komponenten. Genom att även skicka med den definierade funktionen till de underliggande komponen- terna kan de sedan uppdatera datan genom att anropa funktionen vid specifik händelse. På så vis kan de underliggande komponenterna både läsa och uppdatera data som delas med andra komponenter. [71]

I figur D.1 illustreras flödet där två underliggande komponenter skapas i en överliggan- de komponent. Båda initialiseras med den delade datan, där bland annat delade funktioner skickas. En komponent skickar sedan en händelse vilket uppdaterar datan i den överliggande komponenten. Den uppdaterade datan skickas sedan till båda underliggande komponenter för att visualisera den.

D.2.4

Context

Context är ett bibliotek utvecklat av företaget Facebook Inc, som även är skaparna av React. Bibliotekets huvudsakliga syfte är att undvika att skicka data genom flera nivåer av kompo- nenter om den endast används av fåtal komponenter som är långt nere i hierarkin. Biblioteket baseras på att skapa så kallade providers och consumers.

Providers är komponenter högt upp i hierarkin. De initialiserar och distribuerar den da- ta som ska delas med dess underliggande komponenter. För att använda Providers skapas

D.2. Teori Data Barn- komponent Barn- komponent Förälder- komponent Data Händelse Barn- komponent Barn- komponent Förälder- komponent Data Barn- komponent Barn- komponent Förälder- komponent Data 1 2 3

Figur D.1: Flödet då en underliggande komponent uppdaterar delad data i React.

först en klass som definierar providerns initiala värde, som sedan kan återanvändas på olika positioner i renderingen.

Consumers är komponenter som kontinuerligt hämtar delad data när den uppdateras. Consumers skapas genom att sätta den statiska variabeln contextType till önskad typ av provi- der i dess överligande komponenter. Detta gör att de läser den delade datan från från närmast provider av ansatt typ. [20]

D.2.5

Unstated

Unstated är ett bibliotek för tillståndshantering som bygger på Context. Biblioteket bygger på containers vilka är klasser som innehåller egna tillstånd. Dess tillstånd hanteras likt hur komponenters tillstånd hanteras i React. Den enda skillnaden är att detta tillstånd uppdate- ras asynkront, vilket innebär att anrop till den inte väntar på att den ska bli klar, vilket skiljer sig dess motsvariget i React. För att skapa en container skapas en ny klass som ärver Unsta- ted.Container och definierar dess initiala tillstånd samt vilka funktioner den ska innehålla, se kod D.1 för exempel.

1 class Foo extends Container {

2 state = { msg: ’Hello!’ }; 3 bar = () => {

4 this.setState({ msg: ’Bye’ }, 5 () => { 6 console.log(’Updated!’); 7 } 8 ); 9 }; 10 }

Kod D.1: Exempel på användning av context.

För att använda containers används HTML elementet <Provider> som skapar instanser av de containers behövs i dess underliggande element. I en underliggande komponent an- vänds då elementet Subscribe över de komponenter som beror på containerns state, vilket ger tillgång till både state och funktioner hos containern. För exempel, se kod D.2. [84]

D.3. Metod 1 function Component() { 2 return ( 3 <Subscribe to={[Foo]}> 4 {foo => ( 5 <Text>{foo.state.msg}</Text> 6 )} 7 </Subscribe> 8 ); 9 }

Kod D.2: Exempel på en komponent som använder en container.

D.2.6

Redux

Redux är ett bibliotek för tillståndshantering som är avsett för applikationer utvecklade i JavaScript. Biblioteket bygger på att applikationen har ett tillståndsobjekt, som kallas store. Objektet innehåller bland annat ett tillståndsobjekt, vilket representerar applikationens till- stånd. Utöver tillståndet, innehåller store även funktioner för att läsa data på olika sätt, samt så kallade reducers. [72]

En reducer är en funktion som skapar nya tillstånd baserat på föregående tillstånd samt fördefinierade typer av händelser.

Händelseobjektet består dels av data för att beskriva vilken typ av händelse som har inträffat, och data för att beskriva egenskaper hos händelsen. Detta bygger till stor del på Model-View-Controller-strukturen. Se kod D.3 för exempel på hur en store kan skapas, läsas och modifieras. [21] [80]

1 let reducers = function(state = ’’, action){ 2 switch (action.type) { 3 case ’foo’: 4 return action.msg 5 default: 6 return state 7 } 8 } 9

10 let store = createStore(reducers); 11

12 store.subscribe(() => console.log(store.getState())) 13

14 store.dispatch({ type: ’foo’, msg: ’bar’ })

Kod D.3: Exempel på hur en store i Redux kan användas.

D.3

Metod

Studien delades upp i två delar, en förstudie och ett implementationsstadie, där applikatio- nen implementerades med respektive bibliotek.

D.3.1

Förstudie

För att få en förståelse för ramverken utfördes först förstudien. Förstudien baserades på inter- netsökningar på de studerade biblioteken. Huvudsakligen användes bibliotekens egna hem- sidor som grund men även mindre externa exempel på avnändningar av biblioteken använ- des för studien. För att logga tiden det tog att studera biblioteken användes Jira. Först skapa- des en uppgift för förstudie av respektive bibliotek, som sedan användes för att logga tid på varje gång det studerades. Denna tid räknades sedan in i den totala tiden det tog att sätta sig in i biblioteken.

D.4. Resultat

D.3.2

Prototyp

När förstudien var färdig, skapades grafisk prototyp som skulle användas för implementatio- nen av webbsidorna. För att testa bibliotekens förmåga att ändra delad data, läsa delad data kontinuerligt och läsa delad data vid en specifik händelse, definierades olika komponenter.

D.3.3

Implementation

För att implementera applikationerna användes Visual Studio Code för att undvika omlär- ning av utvecklingsmiljö, och för att testa dem användes Google Chrome. Först skapades en grundläggande applikation som innehöll komponenterna som definierats i prototypen. Ef- tersom det grafiska utseendet bakom komponenterna inte var relevant för denna studie, togs ingen större hänsyn till hur de såg ut förutom att de hade matchande färg mot dess represen- tation i prototypen för enklare identifiering.

Efter implementationen av grunden för applikationerna skapades separata grenar i Git för dela upp utvecklingen av applikationen för Unstated och Redux. Implementationerna skedde i två perioder för att undvika omlärning av koncept för biblioteken. Först utveckla- des applikationen med Unstated och sedan med Redux. Tiderna för dessa implementationer loggades i Jira.

D.4

Resultat

D.4.1

Prototyp

Den utvecklade prototypen bestod av tre komponenter, se figur D.2. Komponent A skulle användas för att läsa in text via fältet Textfält A.

Komponent B skulle innehålla en text som kontinuerligt uppdaterades utifrån datan från Textfält A.

Komponent C innehöll både en text och två knappar. Knappen Knapp C1 skulle kunna användas för att hämta texten från Textfält A och visa den i Text C. Den andra knappen, Knapp C2, användes för att radera texten som hade matats in i Textfält A.

Med dessa komponenter skulle dels bibliotekens möjlighet att skriva data från olika källor testas. De skulle även testa möjligheten att läsa delad data både kontinuerligt och vid specifik händelse. Komponent C Komponent A Komponent B Knapp C1 Textfält A Text B Text C Knapp C2

D.5. Implementation i Unstated