IT2810-H26 · clemenbe · Sep 18, 2026 · Sep 18, 2026
@@ -7,6 +7,7 @@ Prosjektet er live på: [http://it2810-02.idi.ntnu.no/project1/](http://it2810-0
 _Skriv en beskrivelse her_
 
 ## Table of Contents
+
 1. [oppsett](#oppsett)
 2. [vm](#vm)
 3. [api](#api)
@@ -20,6 +21,7 @@ _Skriv en beskrivelse her_
 Vi bruker `fnm` med `pnpm`, og `Node.js` v24.
 
 Installasjon kan gjøres med følgende kommandoer (linux):
+
 ```bash
 # Download and install fnm:
 curl -o- https://fnm.vercel.app/install | bash
@@ -234,24 +236,26 @@ Viser ett enkelt filmkort med plakat, tittel, rating og skuespillere. Tar imot m
 Tar imot en liste med filmer (movies: Movie[]) og rendrer ett MovieCard per film med .map(). Den vet ingenting om TMDB eller fetching – det ansvaret ligger i hookene og i Section-komponenten (laster/feilhåndtering). Bygger plakat-URL fra TMDB sin poster_path, med fallback til tom streng hvis filmen mangler plakat. Regner om TMDB sin vote_average (0–10) til prosent (0–100). Layouten er et responsivt grid (repeat(auto-fill, minmax(320px, 1fr))) som går til én kolonne på mobil.
 
 ###### Sidebar.tsx + Sidebar.css
+
 Dette kan også tenkes som venstremenyen på dekstop og den nedre menyen i på mobilview. Den rendrer søkefeltet øverst og deretter enten en utslåbar meny(desktop) eller en fast bunnlinje (mobil). Tar imot onSearch og searchValue for søkefeltet, samt view og onViewChange for å lese og endre hvilke visning appen står i nå. Komponenten eier en egen state, isOpen som styrer om undermenyen er slått ut. Alt det andre vil komme utenfra.
 
 HOME og pila er to separate knapper i samme rad. I CSS vil det være visuelt det samme da Det er bevisst da den ene vil bli brukt til navigasjon og den andre åpner og lukker. Tidigere hadde vi HOME, både som en navigasjons knapp og åpner. Dette førte til at den ikke kunne lukkes og var litt uintuitivt. Pilen som er brukt er tegnet i CSS, og roasjonen styres direkte av aria-expanded. Dette er smart fordi da vil skjermleseren og det visuelle ikke kunne komme ut av sync. Fordi knappen ikke har tekst i seg, har den aria-label som veksler mellom å vise og skjule undermenyen.
 
-Menypunktene ligger i to arrays øvest i fula i stedet for i JSXen. Så nye punkter kan legge sved i ett seperat sted. Mobiletikettene er kortet ned med vilje. Fire knapper i stedet for en dropdown førte til fin symetrisk visning og var lettere å implementere i tilegg. Vi vurderte også å ha symboler, men tok oss ikke tiden for å designe disse knappene. 
+Menypunktene ligger i to arrays øvest i fula i stedet for i JSXen. Så nye punkter kan legge sved i ett seperat sted. Mobiletikettene er kortet ned med vilje. Fire knapper i stedet for en dropdown førte til fin symetrisk visning og var lettere å implementere i tilegg. Vi vurderte også å ha symboler, men tok oss ikke tiden for å designe disse knappene.
 
 ###### SearchField.tsx + SearchField.css
-Søkefeltet, tatt ut av Sidebaren(venstremenyen) fordi den hadde to ansvar samtidig. Komponenten har ingen egen state, teksten kommer inn som en value og sendes ut igjen via onChange, slik at App.tsx eier verdien. Det kalles et kontrollert felt og er grunnen til at menyen kan tømmen søket ved å kalle onSearch. Poppene heter value og onChange med vilje slik t de har samme navn som et vanlig input. 
 
-Labelen er skult visuelt med .visually-hidden. Ikke display:noen. Det siste fjerner elementet fra tilgjenelighetstreet også, og da forsvinner hele hensikten med labelen. htmlFor matcher inputens id. selve søklogikken er laget av en annen i gruppa og er uendret.
+Søkefeltet, tatt ut av Sidebaren(venstremenyen) fordi den hadde to ansvar samtidig. Komponenten har ingen egen state, teksten kommer inn som en value og sendes ut igjen via onChange, slik at App.tsx eier verdien. Det kalles et kontrollert felt og er grunnen til at menyen kan tømmen søket ved å kalle onSearch. Poppene heter value og onChange med vilje slik t de har samme navn som et vanlig input.
 
+Labelen er skult visuelt med .visually-hidden. Ikke display:noen. Det siste fjerner elementet fra tilgjenelighetstreet også, og da forsvinner hele hensikten med labelen. htmlFor matcher inputens id. selve søklogikken er laget av en annen i gruppa og er uendret.
 
 ###### Section.tsx + Section.css
+
 Section e rrammen rundt her seksjon på forsiden Den tar seg av overskriften, id'en som menyen scroller til, g hba som skal vises mens data lastes eller hvis noe går galt. Selve innholdet sendes inn som children.
 
 Grunnen til at den finnes er at MovieList eller har måttet håndtere lasting og feil selv. I tillegg til å vise filmer. nå gjør Section det en gang, og listene kan holde seg til det de er gode på. Mens data hentes vises en grå skeletonboks i stedet for en tom side, og feiler kallet, kommet det en melding.
 
-Overskriften rendres bare hvis title faktisk har innhold. Banner-seksjonen øverst sendes inn uten tittel, og uten den sjekken ville den laget en tom `<h2>`. Det er ikke bare stygt da tomme overskrifter havner i overskriftoversikten en skjermleser navigerer etter, og da står det bare "overskrifter" uten noe mer.  
+Overskriften rendres bare hvis title faktisk har innhold. Banner-seksjonen øverst sendes inn uten tittel, og uten den sjekken ville den laget en tom `<h2>`. Det er ikke bare stygt da tomme overskrifter havner i overskriftoversikten en skjermleser navigerer etter, og da står det bare "overskrifter" uten noe mer.
 
 #### hooks
 
@@ -264,10 +268,10 @@ En React Query-hook som henter skuespillerlisten for én bestemt film via fetchM
 En generisk, gjenbrukbar hook som fungerer som `useState`, men som leser fra og skriver til `sessionStorage` automatisk. Brukes til både sorteringsvalg og minimumsvurdering, og kan gjenbrukes til andre ting senere ved behov. Lesing og skriving er pakket inn i try/catch i tilfelle storage er utilgjengelig (f.eks. i privat nettlesing), og faller da tilbake til en gitt standardverdi.
 
 ###### useMediaQuery.ts
-Vil returnere true eller false for en media query, i mine tilfeller var dette ved bruk av (max-width:700px), som lar meg si at hvis noen åpner ned en brudde under 700px så rendre den riktige menyen. useState passer her på at riktig verdi settes før første render, slik at det ikke skal vises feil visning først. useEffect henger på via window.matchMedia, og return funksjonen fjerner lytteren igjen. uten det hoper lytterne seg opp for hver rendring.
 
-Da desktop og mobil har ulik DOM struktur trenger vi dette både i JSX og CSS og ikke bar ei CSS. I desktop som sagt tidligere ligger undermenyen i HOME og på mobil ligger alle fire knappene flatt på bunnen ved siden av hverandre. Dette vil ikke CSS kunne gjøre. 
+Vil returnere true eller false for en media query, i mine tilfeller var dette ved bruk av (max-width:700px), som lar meg si at hvis noen åpner ned en brudde under 700px så rendre den riktige menyen. useState passer her på at riktig verdi settes før første render, slik at det ikke skal vises feil visning først. useEffect henger på via window.matchMedia, og return funksjonen fjerner lytteren igjen. uten det hoper lytterne seg opp for hver rendring.
 
+Da desktop og mobil har ulik DOM struktur trenger vi dette både i JSX og CSS og ikke bar ei CSS. I desktop som sagt tidligere ligger undermenyen i HOME og på mobil ligger alle fire knappene flatt på bunnen ved siden av hverandre. Dette vil ikke CSS kunne gjøre.
 
 #### layout
 
@@ -320,15 +324,13 @@ regner som om adresselinja i mobilnettleseren ikke finnes, så bunnen av kortet
 
 På tilgjengelighet...
 
-
 ### Kjente begrensninger
 
 - Breakpointet 700px er definert to steder: som streng i useMediaQuery-kallet og i media queries i CSS. Endres det ene uten det andre, blir DOM-struktur og styling ute av synk.
 - padding-bottom på innholdet er hardkodet til høyden på bunnlinja.
 - Scroll til seksjon bruker setTimeout(..., 0) for å vente på at seksjonene er rendret etter et visningsbytte. Det fungerer, men er avhengig av timing – en useEffect som kjører når visningen faktisk har endret seg ville vært riktigere.
 - Hvert MovieCard gjør sitt eget kall til /credits. Caching på én time gjør at samme film ikke hentes på nytt, men første lasting av forsiden gir ett kall per kort i tillegg til filmlista. En samlet henting ville vært bedre.
 
-
 ## Bruk av KI
 
 #### Leona
@@ -360,28 +362,28 @@ _Bruk av KI_:
 
 Dette prosjektet har brukt Claude (Anthropic) som støtte gjennom utviklingsprosessen.
 
-| Dato | Oppgave | Hva KI bidro med |
-|------|---------|-------------------|
-| 03.09 | Oppsett av basisprosjekt | Metodisk plan for prosjektstart (git, Vite-oppsett, komponenter/props/state) |
-| 03.09 | Neste steg etter oppsett | Anbefalt arbeidsrekkefølge: valg av REST API, krav til API (CORS, autentisering, dokumentasjon) |
-| 04.09 | Valg av teknologier | Forklaring av tech-stack: Node.js, TypeScript, TanStack m.m. |
-| 04.09 | Feilsøking React/TypeScript | Debugging av import-feil (default vs. named export) |
-| 11.09 | Bildekarusell-komponent | Løsning for klikkbar bilde-navigasjon (venstre/høyre-soner) |
-| 14.09 | Komponentdesign | Veiledning i React-komponentarkitektur og ansvarsfordeling |
-| 15.09 | API-sikkerhet | Gjennomgang og feilretting av Node/Express reverse-proxy for å skjule TMDB API-nøkkel |
-| 16.09 | Deploy-script | Feilsøking av PATH-problem (pnpm ikke funnet i non-interaktivt shell) |
-| 17.09 | Styling | CSS-løsning for skillelinje under `<section>`-elementer |
-| 17.09 | Dokumentasjon | Søke gjennom chat-historikk for å dokumentere ki-bruk i prosjektet |
+| Dato  | Oppgave                     | Hva KI bidro med                                                                                |
+| ----- | --------------------------- | ----------------------------------------------------------------------------------------------- |
+| 03.09 | Oppsett av basisprosjekt    | Metodisk plan for prosjektstart (git, Vite-oppsett, komponenter/props/state)                    |
+| 03.09 | Neste steg etter oppsett    | Anbefalt arbeidsrekkefølge: valg av REST API, krav til API (CORS, autentisering, dokumentasjon) |
+| 04.09 | Valg av teknologier         | Forklaring av tech-stack: Node.js, TypeScript, TanStack m.m.                                    |
+| 04.09 | Feilsøking React/TypeScript | Debugging av import-feil (default vs. named export)                                             |
+| 11.09 | Bildekarusell-komponent     | Løsning for klikkbar bilde-navigasjon (venstre/høyre-soner)                                     |
+| 14.09 | Komponentdesign             | Veiledning i React-komponentarkitektur og ansvarsfordeling                                      |
+| 15.09 | API-sikkerhet               | Gjennomgang og feilretting av Node/Express reverse-proxy for å skjule TMDB API-nøkkel           |
+| 16.09 | Deploy-script               | Feilsøking av PATH-problem (pnpm ikke funnet i non-interaktivt shell)                           |
+| 17.09 | Styling                     | CSS-løsning for skillelinje under `<section>`-elementer                                         |
+| 17.09 | Dokumentasjon               | Søke gjennom chat-historikk for å dokumentere ki-bruk i prosjektet                              |
 
 **Oppsummert:** KI er brukt til prosjektplanlegging, komponentarkitektur, feilsøking, API-sikkerhet, styling og CI/CD-oppsett. All kode er gjennomgått og forstått før den er tatt i bruk.
 
 **Erfaringer:**
 KI var nyttig gjennom hele prosjektet, spesielt til å effektivisere lesing av dokumentasjon — i stedet for å lese gjennom store mengder API- eller bibliotek-dokumentasjon selv, kunne KI raskt oppsummere det som var relevant. Den var også til hjelp for å finne kilder og eksempler på hvordan ting bør gjøres, både i form av beste praksis og alternative løsninger å vurdere. På den tekniske siden ga KI god generell støtte med TypeScript-syntaks (typing, generics, korrekt bruk av interfaces/types), og fungerte som en rask referanse for kommandoer man ellers måtte slått opp (git, npm/pnpm, deploy-relaterte kommandoer). Ved konkret feilsøking — som import-feil i React-komponenter, PATH-problemer i deploy-scriptet, var KI effektiv til å peke ut sannsynlig årsak og forslag til løsning, noe som sparte tid sammenlignet med å feilsøke fra bunnen selv. Samtidig var det nødvendig å alltid kvalitetssikre og teste forslagene selv, siden KI ikke alltid traff riktig på første forsøk og enkelte ganger krevde oppfølgingsspørsmål eller mer kontekst for å komme til en fungerende løsning.
 
-
 ## Template under i tilfelle andre vil ha samme oppsett for KI-bruk
+
 #### [Navn]
 
 | Dato | Oppgave | Hva KI bidro med |
-|------|---------|-------------------|
-| | | |
+| ---- | ------- | ---------------- |
+|      |         |                  |