Commit 365ef58b authored by Turid Cecilie Dahl's avatar Turid Cecilie Dahl
Browse files

Written more on README

parent 8b38e53b
Dokumentasjonen skal diskutere, forklare og vise til alle de viktigste valgene og løsningene på krav til funksjonalitet og krav til teknologi. 800-1000 ord er en fornuftig lengde.
## Dokumentasjon ## Dokumentasjon
### `React` ### `React`
...@@ -11,6 +9,8 @@ Underveis i prosjektet har gruppen opprettholdt kravet om å kunne de ordinære ...@@ -11,6 +9,8 @@ Underveis i prosjektet har gruppen opprettholdt kravet om å kunne de ordinære
SVG-filene og json-filene som er brukt lastes inn via ajax sin *fetch*-metode. Dette gjør at filene kun lastes inn dersom det er nødvendig. I motsetning gjøres henting av lyd kun med vanlig importering. SVG-filene og json-filene som er brukt lastes inn via ajax sin *fetch*-metode. Dette gjør at filene kun lastes inn dersom det er nødvendig. I motsetning gjøres henting av lyd kun med vanlig importering.
Gruppen har valgt å ikke implementere noen egen form for caching, ettersom dette allerede eksisterer i moderne nettlesere. Dette er vist med bildene caching1 og caching2. I caching1 er caching disabled, dette vises med at status code er 200 OK. Det vil si at bildet har blitt hentet, og at dragon bildet ikke var lagret i cachen. Caching2 viser at når man har caching abled, så får man status code 304 Not Modified. Den statusen betyr at man ikke trengte å hente dragon bildet ettersom det var allerede lagret i cachen, og hadde ikke blitt modifisert. Gruppen har valgt å ikke implementere noen egen form for caching, ettersom dette allerede eksisterer i moderne nettlesere. Dette er vist med bildene caching1 og caching2. I caching1 er caching disabled, dette vises med at status code er 200 OK. Det vil si at bildet har blitt hentet, og at dragon bildet ikke var lagret i cachen. Caching2 viser at når man har caching abled, så får man status code 304 Not Modified. Den statusen betyr at man ikke trengte å hente dragon bildet ettersom det var allerede lagret i cachen, og hadde ikke blitt modifisert.
For alle tekster som er brukt, har gruppen inkludert sitattegn og opphavsperson. Bildene er fra Pixabay, som tilbyr en stor samling gratis arkivbilder, vektorer og kunstillustrasjoner. Alle bilder er utgitt under Creative Commons CC0. Lydklippene brukt er hentet fra Freesound eller spilt inn selv.
### `HTML Web Storage` ### `HTML Web Storage`
...@@ -39,7 +39,7 @@ Git har blitt hyppig brukt gjennom hele prosjektprosessen. Etter *create-react-a ...@@ -39,7 +39,7 @@ Git har blitt hyppig brukt gjennom hele prosjektprosessen. Etter *create-react-a
Hver uke har det blitt laget issues som har blitt utdelt til et medlem og satt frist til neste møte, neste uke eller senere. Den første uken av prosjektet prøvde gruppen å ha en branch per medlem. Dette fungerte greit, men andre uke ønsket gruppen å heller ha brancher basert på hvilken funksjonalitet som ble utviklet. Derfor ble det laget en branch til hver issue. I noen tilfeller ble tilhørende issues samlet til en overordnet branch. Gruppen kunne vurdert å da slå sammen issuesene som ble tilhørende samme branch, men allikevel ønsket gruppemedlemmene å ha relativt detaljerte issues og valgte ikke å slå issuesene sammen. Etter å ha prøvd begge disse fremgangsmåtene for branch-struktur, har gruppen foretrukket å ha en branch per issue/overordnede issue. Det kan komme av at da blir det mer oversiktlig og at andre kan jobbe på en annen branch lettere om de ønsker. På den andre siden, kan det bli litt rotete med så mange brancher. Dermed har ikke gruppen helt fastslått hva slags branch-struktur som vil benyttes i fremtidige prosjekter. Hver uke har det blitt laget issues som har blitt utdelt til et medlem og satt frist til neste møte, neste uke eller senere. Den første uken av prosjektet prøvde gruppen å ha en branch per medlem. Dette fungerte greit, men andre uke ønsket gruppen å heller ha brancher basert på hvilken funksjonalitet som ble utviklet. Derfor ble det laget en branch til hver issue. I noen tilfeller ble tilhørende issues samlet til en overordnet branch. Gruppen kunne vurdert å da slå sammen issuesene som ble tilhørende samme branch, men allikevel ønsket gruppemedlemmene å ha relativt detaljerte issues og valgte ikke å slå issuesene sammen. Etter å ha prøvd begge disse fremgangsmåtene for branch-struktur, har gruppen foretrukket å ha en branch per issue/overordnede issue. Det kan komme av at da blir det mer oversiktlig og at andre kan jobbe på en annen branch lettere om de ønsker. På den andre siden, kan det bli litt rotete med så mange brancher. Dermed har ikke gruppen helt fastslått hva slags branch-struktur som vil benyttes i fremtidige prosjekter.
### `Kilder` ### `Kilder`
#3 Try REACTJS Tutorial - Display Json Data. (2018). Hentet fra: Try REACTJS Tutorial - Display Json Data. (2018). Hentet fra:
https://www.youtube.com/watch?v=9C85o8jIgUU&fbclid=IwAR08HyNZ-VLLTn50-NO7ogQB21CqWJmxRKlWQqhE3rtPjgMDUsQrbCDNOQU https://www.youtube.com/watch?v=9C85o8jIgUU&fbclid=IwAR08HyNZ-VLLTn50-NO7ogQB21CqWJmxRKlWQqhE3rtPjgMDUsQrbCDNOQU
Berebecki, P. (udatert). React JS Radio buttons. Hentet fra CodePen website: Berebecki, P. (udatert). React JS Radio buttons. Hentet fra CodePen website:
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment