Feilsøking i JavaScript for nybegynnere: slik finner du de vanligste feilene steg for steg

JavaScript er ofte det første språket mange møter når de begynner med webutvikling, men også et av de mest forvirrende når noe går galt. Plutselig “skjer ingenting”, nettsiden svarer ikke, eller du får en kryptisk feilmelding i nettleseren.

I denne artikkelen går vi gjennom konkrete teknikker for feilsøking i JavaScript, med fokus på hva du kan gjøre i nettleseren for å forstå hva som skjer, finne feilen raskere og unngå å gjenta de samme tabbene.

Start med utviklerverktøyene i nettleseren

Nesten all feilsøking i JavaScript starter i nettleserens utviklerverktøy. Disse er innebygd i moderne nettlesere som Chrome, Edge, Firefox og Safari, og gir deg et vindu inn i hva som faktisk skjer i skriptene dine.

For å åpne verktøyene bruker du vanligvis F12 eller høyreklikker på siden og velger “Inspiser”. Der finner du typisk en fane som heterConsoleog en som heterSourcesellerDebugger.

Console: stedet der JavaScript roper om hjelp

Console-fanen viser feil, advarsler og meldinger fra skriptene dine. Hvis JavaScript slutter å virke uten at du forstår hvorfor, er det første du bør gjøre å sjekke om det ligger en rød feilmelding der.

En typisk feilmelding kan se slik ut:Uncaught ReferenceError: myVariable is not defined. Da vet du at JavaScript prøver å bruke en variabel som ikke finnes i det øyeblikket.

Bruk console.log riktig, ikke bare kast det inn

console.log()er ofte det første verktøyet nybegynnere bruker for å forstå hva som skjer. Det er fortsatt nyttig, men blir enda bedre når du bruker det strukturert og bevisst i stedet for å spamme alt mulig til Console.

Et godt mønster er å logge både en kort tekst og verdien, for eksempel:console.log(“Brukerdata etter innlasting:”, userData). Da ser du både hvor i flyten du er, og hvilken verdi variabelen har.

Typiske ting det lønner seg å logge

• Input-verdier før du gjør beregninger eller sender noe til et API
• Resultatet av en funksjon, spesielt hvis den gir et uventet svar
• Statusflagg somisLoading,isLoggedIneller lignende
• Respons fra nettverkskall før du bruker dataene videre

Hvis Console blir uoversiktlig, kan du midlertidig fjerne gamleconsole.log()eller samle data i ett par godt navngitte logger i stedet for ti forskjellige.

Forstå de vanligste JavaScript-feilene

Selv om feilmeldinger kan virke skumle i starten, repeterer de ofte de samme mønstrene. Når du lærer deg å gjenkjenne typene feil, blir det mye raskere å rette dem.

Her er noen typiske meldinger du vil møte, og hva de som regel betyr i praksis.

ReferenceError og TypeError

ReferenceError: X is not definedbetyr at JavaScript ikke finner navnet du bruker. Kanskje du har stavet feil, brukt variabelen før du deklarerte den, eller den er kun synlig inne i en annen funksjon.

TypeError: Cannot read property ‘y’ of undefinedbetyr at du prøver å lese noe fra en variabel som egentlig erundefinedellernull. Da bør du logge variabelen før du bruker den, og se når den mister verdien du forventer.

SyntaxError og små skrivefeil

SyntaxErroroppstår når JavaScript i det hele tatt ikke klarer å lese koden, for eksempel på grunn av en manglende parentes eller krøllparentes. Disse feilene stopper ofte all videre kjøring av skriptet.

Her er det lurt å se på linjenummeret i feilmeldingen, men også linjene rett over. En manglende avsluttende parentes på linje 10 kan føre til feilmelding på linje 11 eller 12.

Bruk breakpoint i stedet for bare console.log

Console.log er fint, men noen ganger trenger du å stoppe programmet akkurat på et bestemt sted og se hva som skjer steg for steg. Det gjør du med breakpoint iSources– ellerDebugger-fanen i nettleseren.

Finn JavaScript-filen, klikk på linjenummeret der du vil stoppe, og last inn siden på nytt. Når scriptet når den linjen, stopper det, og du kan inspisere variabler, trinn for trinn.

Slik jobber du systematisk med breakpoint

• Sett breakpoint rett før du tror feilen oppstår, ikke midt inne i kaoset
• Bruk knappene for å gå til neste linje, eller hoppe inn/ut av funksjoner
• Se på “Scope” eller “Local” panel for å se alle variabler tilgjengelig der du står
• Endre en verdi midlertidig i Console for å teste en hypotese uten å redigere filene

Jobb deg bakover fra symptomet til årsaken

En vanlig felle er å fokusere på stedet der alt kollapser, i stedet for å undersøke hvor ting begynte å gå galt. Feilsøking blir mye enklere hvis du starter med symptomet og så går et hakk bakover av gangen.

Hvis en knapp “ikke virker”, kan du sjekke i denne rekkefølgen: Trigges klikk-hendelsen, får du riktig data inn i funksjonen, og er DOM-elementet du prøver å endre faktisk til stede på siden.

Et enkelt mønster du kan følge

1. Beskriv feilen konkret: “Når jeg klikker X, skjer Y, men jeg forventer Z”
2. Logg enkelte nøkkelverdier i den delen av flyten der feilen viser seg
3. Flytt loggingen gradvis bakover til du finner det første stedet der noe avviker
4. Bruk breakpoint hvis det er vanskelig å se sekvensen med bare logging

Lær deg å lese feilmeldinger uten å få panikk

Det viktigste med feilmeldinger er ikke å forstå alt, men å trekke ut to ting: hvilken type feil det er, og hvor i filene den dukker opp. Resten kan du ofte slå opp etter behov.

En nyttig øvelse er å ta deg tid til å lese hele meldingen sakte, og skrive ned med egne ord hva du tror den betyr. Deretter kan du søke på delen av meldingen som er språklig nøytral, for eksempel“Cannot read property of undefined”.

Bygg gode vaner som gir færre feil over tid

Feilsøking blir enklere hvis du skriver kode på en måte som er lett å undersøke senere. Små funksjoner med tydelige navn er enklere å teste enn én stor blokk som gjør alt på en gang.

Det kan også være lurt å gi variabler noe mer beskrivende navn enn baredataellerres, spesielt når du logger dem. Da skjønner du raskere hva som skjer når du kommer tilbake til prosjektet etter en pause.

Noen enkle vaner du kan starte med i dag

• Hold funksjoner korte, gjerne bare én klart definert oppgave
• Gi loggmeldinger tydelige, konsekvente prefiks, for eksempel[LOGIN]eller[FORM]
• Test små biter interaktivt i Console før du bygger dem inn i større flyt
• Les gjennom nye feilmeldinger rolig før du gjør endringer

Feilsøking er en ferdighet som vokser med erfaring. Poenget er ikke å unngå alle feil, men å bli trygg på at du kan finne dem igjen uten å bruke hele dagen på gjetting.