Finn ut hvordan du feilsøker JavaScript ved hjelp av Chrome DevTools. Sett kjøringen på pause på en hvilken som helst linje

Evnen til å feilsøke kode er en viktig ferdighet for en utvikler. Det er viktig å forstå og bruke det store utvalget av feilsøkingsverktøy som finnes for et bestemt programmeringsspråk.

Dessverre virker feilsøking kanskje ikke like opplagt når du arbeider med JavaScript utenom full funksjonalitet. IDE-er. I hvert fall — ved første øyekast.

Denne artikkelen vil se på hvordan du kan feilsøke JavaScript-kode i Google Chrome Dev Tools og i Visual Studio Code-editoren.

Oversetterens notat: ved å klikke på denne lenken kan du se videoversjonen av denne artikkelen Feilsøking av JavaScript i Google Chrome og Visual Studio Code på engelsk.

Forhåndsinnstillinger

I denne artikkelen vil feilsøkingsprosessen bli diskutert ved hjelp av et eksempel. testapplikasjon kalt "Quick Chat":

Du har to måter å bruke denne applikasjonen på. Du kan lage den selv ved å bruke denne en serie videotimer. Eller du kan bruke kildekoden til en ferdig Quick Chat-applikasjon:

Uansett hvilket alternativ du velger, må du kjøre Quick Chat-appen lokalt.

Du kan kjøre applikasjonen fra Node.js ( hvordan gjør jeg det). Eller bruk plugin under Visuelt studio Kode kalt Live Server.

Hvis du er ny til å jobbe med denne plugin-modulen, kan du lære hvordan du jobber med den ved å bruke denne videoen — Live Server Extension i Visual Studio Code.

Oversetterens notat: video på engelsk.

MED teknisk poeng Tilsynelatende får jeg brukernavnet feil ved å bruke usernameInput.text i stedet for det korrekte usernameInput.value-alternativet. Hvis jeg gjorde en slik feil i det virkelige liv, ville min første tanke være å bruke console.log()-verktøyet.

Men dette er ikke akkurat tilfellet som kan hjelpe meg, som du kan se på bildet nedenfor. Hvis det å bruke console.log() også var din første tanke, har du kommet til rett sted og gjør det rette ved å lese denne artikkelen!

Grunnleggende om feilsøking

La oss starte med det grunnleggende. Tanken bak feilsøking er at du kan sette såkalte bruddpunkter ( bruddpunkter) for å stoppe programkjøringen på et bestemt sted.

Dette gir deg, som utvikler, muligheten til å se på den nåværende tilstanden til applikasjonen og sjekke for eksempel verdiene til variabler i den. Du kan til og med gå lenger og spore valgfrie variabler, slik at når applikasjonen stopper, kan du sjekke verdiene til disse variablene.

Etter å ha satt et bruddpunkt ( bruddpunkt) i koden er det som regel flere alternativer for ytterligere handlinger:

fortsette programkjøringen
gå trinn for trinn gjennom alle stadier av programmet - linje for linje
gå ut av den gjeldende funksjonen du er i
gå til neste funksjon

Du vil også ha tilgang til å se anropsstakken ( ringestabel). Med andre ord, siden funksjoner i et program kan kalle andre funksjoner for utførelse, kan du vise samtalehistorikk disse funksjonene.

Feilsøking inn Google Chrome

For å begynne å feilsøke applikasjonen din i Google Chrome-nettleseren, legg til en hendelsesbehandler med clickBtn-knapp operatør debugger som nedenfor:

Når programkjøringen når linjen med debugger-setningen, vil applikasjonen bli suspendert og feilsøkingsverktøyene til Google Chrome-nettleseren aktiveres automatisk.

Vær oppmerksom på at applikasjonen i nettleservinduet er skyggelagt grå for å vise at den er satt på pause. Vær også oppmerksom på at Kilder-fanen i Chrome Dev Tools åpnes automatisk:

La oss se hva vi ser på Kilder-fanen.

Kilder-fanen

Det første du kanskje legger merke til på denne fanen er en kopi av programmets kildekode. Dette er koden som nettleseren har lastet inn og fungerer med.

Du kan også legge merke til at kodelinjen med feilsøkingssetningen er uthevet i blått for å fortelle oss at programmet har sluttet å kjøre på dette punktet i koden:

Google Chrome-nettleseren gir oss muligheten til å se kildekoden til en applikasjon. Når du har kildekoden foran deg, kan du installere i den bruddpunkter.

Et bruddpunkt er ment å indikere et sted hvor programkjøringen skal stoppes. Operatør debugger, som vi brukte i eksemplet ovenfor, fungerer som bruddpunkt, men i applikasjonens kildekode er det slik bruddpunkt det trenger ikke være bare én.

Breakpoint er en bevisst stopp eller pause i programkjøringen.

Å legge til bruddpunkt, må du klikke på takrenne — feltet til venstre for nummereringen av kodelinjer. Når du har fullført denne handlingen, vil du legge merke til at Google Chrome-nettleseren automatisk har lagt til dette bruddpunkt til "Knekkpunkter"-listen:

Omfang-fanen

Omfang-fanen er der du kan overvåke variabler i applikasjonen din. Vær oppmerksom på at denne fanen har tre seksjoner: lokalt omfang ( Lokalt), globalt omfang ( Global) og manusdel ( Manus).

I skriptdelen kan du spore variabler i omfanget av gjeldende skript:

Du vil bruke mesteparten av tiden på å feilsøke applikasjonen i denne fanen. Dette er et mye mer effektivt alternativ til å bruke flere console.log() s.

Se-fanen

Som nevnt tidligere, i tillegg til å vise variabler i fanen Scope, kan du også definere variabler hvis verdier du ønsker å overvåke gjennom programmets kjøring.

Ved å legge til en variabel i Watch-fanen, hver gang du angir et bruddpunkt, kan du raskt sjekke verdien til den variabelen (som kan være udefinert avhengig av hvor du er i koden).

Klikk på plusstegnet og skriv inn navnet på variabelen du vil overvåke, i vårt tilfelle brukernavnInput:

Trinn for trinn utførelse, anropsstabel og bruddpunktliste

Kategorien "Kilder", som ligger i nedre venstre hjørne av feilsøkingsvinduet, lar deg se en liste over bruddpunkter, anropsstakken ( ringestabel) etc.

I ringestabel Det er bare én funksjon som er hendelsesbehandleren for påloggingsknappen. Funksjonen er oppført fordi det er den eneste funksjonen som ble kalt på dette øyeblikket. Siden noen funksjoner kan kalle andre funksjoner for utførelse, vil denne kjeden bli oppdatert tilsvarende.

Legg også merke til pilknappene øverst på skjermen. Disse samsvarer med funksjonene ovenfor for å fortsette å kjøre koden eller gå gjennom den linje for linje ( stepping). Jeg vil anbefale å teste disse knappene litt for å bli vant til hvordan koden kan utføres.

Endelig er det Forskjellige typer bruddpunkter som kan settes. La oss se på et eksempel på å lage et betinget bruddpunkt ( betinget bruddpunkt), som bare vil avfyres når en viss betingelse er oppfylt.

La oss for eksempel si at vi ønsker å forhindre at påloggingsknapphendelsen kun behandles når brukeren prøver å logge på uten å skrive inn et brukernavn.

Vi kan gjøre dette ved å klikke Høyreklikk mus på rennefeltet og skape bruddpunkt med følgende betingelse — usernameInput.text === "" :

Ved feilsøking Raske apper Chat, hvis du klikker på påloggingsknappen uten brukernavn, vil dette bli lansert bruddpunkt. Ellers vil koden fortsette å kjøre som vanlig.

Vær oppmerksom på at det er enda flere tilgjengelige alternativer bruddpunkter, som ikke er omtalt i denne artikkelen.

Feilsøking i Visual Studio Code

Chrome Developer Tools er et av de beste i sitt slag. Som du allerede har sett, tilbyr den utmerkede funksjoner og funksjonalitet for feilsøking av applikasjonen.

Det har imidlertid Visual Studio Code-utviklingsteamet gjort stor jobb for å gjøre feilsøkingsprosessen i denne editoren enda mer perfekt.

Jeg liker virkelig Visual Studio Code og bruker mer tid på det enn noen annen koderedigerer. Denne prosessen inkluderer også feilsøking.

For å begynne å feilsøke kode i VS Code, må du installere Debugger for Chrome-plugin:

La oss ta en titt på Debug-fanen. Som standard er den plassert i redaktørens sidefelt. Åpne denne fanen ved å klikke på ikonet som ser ut som en feil ( feil).

Når du åpner dette panelet, vil du se verktøy som ligner veldig på de vi så i Google nettleser Chrome — variabler, ringestabel, bruddpunkter:

Flertall funksjonalitet, som vi behandlet i Chrome Dev Tools, er også tilgjengelig i VS-kode.

Nå som vi er kjent med Feilsøkingsfanen, må vi lage en konfigurasjon som vil fortelle VS Code-editoren hvordan de skal feilsøke applikasjonen vår.

VS Code lagrer feilsøkingskonfigurasjonen i en launch.json-fil i .vscode-mappen. For å få VS-kode til å opprette denne filen for oss, åpne "Ingen konfigurasjoner" rullegardinlisten i redigeringsmenyen og velg "Legg til konfigurasjon".

VS Code lagrer feilsøkingskonfigurasjonen i en fil kalt launch.json inne i .vscode-mappen

Velg deretter "Chrome" fra denne listen.

Det er lett å gå seg vill når du skriver JavaScript-kode uten en debugger.

JavaScript-feilsøking

Vanskelig å skrive JavaScript-kode uten debugger.

Koden din kan inneholde syntaksfeil eller logiske feil som er vanskelige å diagnostisere.

Ofte, når JavaScript-koden inneholder feil, vil ingenting skje. Det er ingen feilmeldinger, og du vil ikke få noen instruksjoner om hvor du skal lete etter feil.

Vanligvis vil det oppstå feil hver gang du prøver å skrive noe ny kode JavaScript.

JavaScript-feilsøkere

Finner feil i programkode kalt feilsøkingskode.

Feilsøking er ikke så lett. Men heldigvis alt moderne nettlesere har en innebygd debugger.

Innebygde debuggere kan slås av og på, noe som tvinger feil til å rapporteres til brukeren.

Med en debugger kan du også sette bruddpunkter (steder hvor kjøring av kode kan stoppes) og undersøke variabler mens koden kjører.

Generelt, ellers følg instruksjonene nederst på denne siden, vil du aktivere feilsøking i nettleseren ved å bruke F12-tasten, og velge "Konsoll" fra feilsøkingsmenyen.

console.log() Metode

Hvis nettleseren din støtter feilsøking, kan du bruke console.log() for å vise JavaScript-verdier i feilsøkingsvinduet:

eksempel

Min første nettside

a = 5;
b = 6;
c = a + b;
console.log(c);

Sette bruddpunkter

I feilsøkingsvinduet kan du angi bruddpunkter i JavaScript-koden.

På hver kontrollpunkt, vil JavaScript slutte å kjøre og lar deg utforske JavaScript-verdiene.

Etter å ha undersøkt verdien, kan du fortsette å utføre koden (vanligvis ved å bruke avspillingsknappen).

Søkeord for feilsøking

Debugger nøkkelord stopper JavaScript-utførelse og kaller (hvis noen) til feilsøkingsfunksjonen.

Denne har samme funksjon ved å sette et bruddpunkt i debuggeren.

Hvis feilsøking ikke er tilgjengelig, har feilsøkingssetningen ingen effekt.

Med feilsøkeren aktivert, vil denne koden slutte å kjøre før den kjører den tredje linjen.

Store nettlesere "Feilsøkingsverktøy"

Vanligvis vil du aktivere feilsøking i nettleseren med F12, og velge "Konsoll" fra feilsøkingsmenyen.

Ellers følger du disse trinnene:

Chrome

Åpne nettleseren din.
Velg verktøy fra menyen.
Til slutt velger du Konsoll.

Firefox Firebug

Åpne nettleseren din.
Gå til nettsiden:
http://www.getfirebug.com
Følg instruksjonene som:
installer Firebug

Internet Explorer

Åpne nettleseren din.
Velg verktøy fra menyen.
Velg utviklerverktøy fra verktøy.
Til slutt velger du Konsoll.

Opera

Åpne nettleseren din.
Gå til nettsiden:
http://dev.opera.com
Følg instruksjonene som:
legg til en utviklerkonsollknapp på verktøylinjen.

Safari Firebug

Åpne nettleseren din.
Gå til nettsiden:
http://extensions.apple.com
Følg instruksjonene som:
installer Firebug Lite.

Safari Utviklingsmeny

Gå til Safari, Innstillinger, Avansert i hovedmenyen.
Merk av for "Aktiver Vis meny i menylinjen Utvikl".
Når det nye "Utvikle"-alternativet vises i menyen:
Velg "Vis feilkonsoll".

Forfatterens notat: console.log kan fortelle deg mye om en applikasjon, men den lar deg ikke virkelig feilsøke koden din. Den nye JS-feilsøkeren i Firefox vil hjelpe deg å skrive kode raskere og uten feil. En artikkel om driftsprinsippet til denne feilsøkeren.

I dette eksemplet vil vi åpne et veldig enkelt program som gjør JavaScript-feilsøking enkelt. Selve applikasjonen kjører på basic åpen kilde JS-rammeverk. Åpne den inn siste versjon Firefox Developer Edition og kjør debugger.html ved å bruke kombinasjonen Alternativtaster+ Cmd + S på Mac eller Shift + Ctrl + S på Windows. Debuggeren er delt inn i 3 paneler: et fillistepanel, et kodepanel og en verktøylinje.

Verktøylinjen er delt inn i verktøylinje, klokkeuttrykk, bruddpunkter, anropsstabel og områder.

Slutt å bruke console.log

Vi ønsker å bruke console.log til å feilsøke koden vår. Vi legger bare til et kall til koden for å finne ut verdien av variabelen, og det er det, ikke sant? Denne tilnærmingen vil fungere, men den er tungvint og tidkrevende. I dette eksemplet vil vi gå gjennom applikasjonen ved å bruke debugger.html for å finne verdien til en variabel.

Med debugger.html kan du dykke dypere inn i koden din ved å legge til et bruddpunkt på en linje. Knekkpunkter setter feilsøkeren på pause slik at du kan se på koden. I dette eksemplet vil vi legge til et bruddpunkt på linje 13 i app.js-filen.

Legg nå oppgaven til listen. Koden stopper ved addTodo-funksjonen, og vi kan se på verdien av feltet i koden. Hold markøren over en variabel for å se verdien osv. På denne måten kan du se ankere, appleter, barneelementer etc.:

Den samme informasjonen finner du i panelet Områder.

Når skriptet er satt på pause, kan du utføre linjene trinn for trinn ved hjelp av verktøylinjen. Fortsett/pause-knappene gjør akkurat det de sier. Gå over-knappen utfører gjeldende linje kode, Enter – går inn i funksjonen, Exit – kjører gjeldende funksjon før du forlater samtalen hennes.

Overvåk verdien av en monovariabel også ved å bruke klokkeuttrykk. Bare skriv inn et uttrykk i Expressions to Watch-boksen, og feilsøkeren vil se etter det mens koden din kjøres. I eksemplet ovenfor kan du legge til tittel- og gjøremålsuttrykk, og feilsøkeren vil bryte ned verdiene når de er tilgjengelige. Spesielt nyttig når:

Du går gjennom koden og ser verdien endres;

Du feilsøker den samme koden mange ganger og vil se generelle verdier;

Du prøver å finne ut hvorfor den jævla knappen ikke fungerer.

Du kan også feilsøke React/Redux-applikasjoner ved å bruke debugger.html. Hvordan det fungerer:

Naviger til komponenten du vil feilsøke.

Se komponentdiagrammet til venstre (fungerer i en klasse).

Legg til bruddpunkter til passende funksjoner.

Trykk på pause og observer egenskapene og tilstandene til komponenten.

Anropsstakken er forenklet, slik at du ser applikasjonskode blandet med rammeverket.

debugger.html lar deg se på forvirrende eller forminsket kode som kan forårsake feil. Spesielt nyttig når du arbeider med vanlige rammeverk som React/Redux. Feilsøkeren kjenner til komponenten du stoppet på og vil vise en forenklet anropsstabel, komponentdiagram og egenskaper. Nedenfor forklarer utvikler Amit Zur hvordan han bruker Firefox-kodefeilsøkeren på JS Kongress:

Hvis du vil se nærmere på den nye debugger.html, sjekk ut Mozilla Developer Playground. Vi har laget en serie opplæringsprogrammer for å hjelpe utviklere med å lære hvordan de effektivt kan bruke verktøyet til å feilsøke kode.

Åpen kildekode-utviklerverktøy

Debugger.html-prosjektet ble lansert for omtrent 2 år siden sammen med en fullstendig overhaling av Firefox DevTools. Vi ønsket å flytte DevTools til moderne teknologier, åpne dem for utviklere over hele verden. Og fordi teknologien er åpen, kan den fritt vokse til noe den lille gruppen på Mozilla aldri kunne ha forestilt seg.

JS er grunnlaget for enhver avansert nettapplikasjon, så en kraftig debugger var en kjernedel av verktøysettet. Vi ønsket å lage noe raskt, enkelt å bruke, tilpasningsdyktig – i stand til å feilsøke ethvert nytt JS-rammeverk. Vi bestemte oss for å bruke populære nettteknologier fordi vi ønsket å jobbe nærmere fellesskapet. Denne tilnærmingen ville forbedre selve debuggeren - hvis vi tok i bruk Webpack og begynte å bruke byggeverktøyet og kildekartene internt, ville vi ønsket å forbedre kildekartlegging og hot reloading.

debugger.html er skrevet i React, Redux og Babel. React-komponenter er lette, testbare og enkle å designe. For rask UI-prototyping og dokumentasjon av vanlige komponenter bruker vi React Storybook. Dette gjør det lettere å jobbe med ulike JS-rammeverk (som React). Babels frontend lar deg gjøre ting som å vise Component-klassen og dens funksjoner i venstre sidefelt. Vi kan også sette bruddpunkter på funksjoner og de vil ikke flytte seg hvis du endrer koden.

Redux-handlinger er en ren UI API. Imidlertid kan de også brukes til å lage en uavhengig JS Debugger CLI. Redux-depotet har velgere for spørring nåværende situasjon feilsøking Våre enhetstester kjører Redux-handlinger og simulerer nettlesersvar. Integrasjonstester bringer nettleseren til handling med Redux-feilsøkingshandlinger. Selve funksjonsarkitekturen er designet for testing.

Vi har stolt på Mozilla-utviklerfellesskapet hvert eneste trinn. Prosjektet ble publisert på GitHub, og teamet vårt nådde ut til utviklere over hele verden, og de svarte. Helt i begynnelsen var automatiserte tester avgjørende for samfunnet. Testene utførte regresjon og dokumenterte atferd som lett kunne overses. Det er derfor et av de første trinnene var å skrive enhetstester for Redux-handlinger og flyttyper for Redux-butikken. Faktisk sørget fellesskapet for at Flow og Jest-dekning bidro til å sikre at hver fil ble skrevet og testet.

Som utviklere tror vi at verktøyene er sterkere jo flere utviklere er involvert. Kjerneteamet vårt har alltid vært lite (2 personer), men i gjennomsnitt var det 15 assistenter per uke. Fellesskapet ga oss forskjellige perspektiver, noe som hjalp oss med å forutse utfordringer og skrive funksjoner vi aldri hadde forestilt oss. Vi formaterer for øyeblikket anropsstabler for 24 biblioteker. Vi visste ikke engang om mange av dem. Vi viser også Webpack- og Angular-kart i kildetreet.

Vi planlegger å flytte alle Firefox DevTools til GitHub slik at de kan brukes og forbedres flere mennesker. Vi tar gjerne imot din hjelp. Du kan gå til vår prosjektside debugger.html på GitHub. Vi har skrevet en hel liste med instruksjoner for å kjøre feilsøkeren på maskinen din, der du kan endre hva du vil. Bruk den til å feilsøke JS-kode for hva som helst - nettlesere, terminaler, servere, telefoner, roboter. Hvis du ser noe som kan forbedres, skriv til oss på GitHub.

Glem feilsøking med console.log for alltid! Lær hvordan du bruker bruddpunkter for å feilsøke kode i verktøy Chrome-utvikler

Oversettelse av artikkelenBrandon Morelli : Lær hvordan du feilsøker JavaScript med Chrome DevTools . Publisert med tillatelse fra forfatteren.

Det kan være vanskelig å finne og rette feil. Du kan bli fristet til å bruke console.log() ukontrollert for å få koden til å fungere riktig. Det er ferdig!

Denne artikkelen handler om den riktige måten å feilsøke på! Du lærer hvordan du bruker Chrome-utviklerverktøy til å angi bruddpunkter og undersøke kode. Denne tilnærmingen er ofte den mest effektiv metode Finne og rette feil i koden.

Denne opplæringen viser hvordan du feilsøker ett spesifikt problem, men en lignende arbeidsflyt er nyttig for å feilsøke alle typer JavaScript-feil.

Trinn 1: Gjenskaper feilen

Å gjengi feilen – det første trinnet til feilsøking – betyr å oppdage serien av handlinger som fører til at den dukker opp. Du må kanskje reprodusere feilen mange ganger, så det anbefales å eliminere unødvendige trinn.

For å reprodusere feilen skal vi fikse under denne håndboken, følg instruksjonene nedenfor:

Her er nettsiden vi skal jobbe med for denne artikkelen. Åpne den i en ny fane: DEMO.
Skriv inn 5 i demoen for nummer 1.
Skriv inn 1 for nummer 2.
Klikk på Legg til nummer 1 og nummer 2.
Se på etiketten under inngangene og knappen. Hun sier at 5 + 1 = 51.

Oops. Dette er et feil resultat. Resultatet skal være 6. Dette er feilen vi skal fikse.

Trinn 2: Sett kodekjøring på pause ved å bruke et bruddpunkt

DevTools lar deg sette koden på pause midt i utførelse og hente verdiene alle variabler på dette tidspunktet. Verktøyet for å sette kode på pause kalles et bruddpunkt. Prøv det nå:

Gå tilbake til demoen og åpne DevTools ved å trykke Command+Option+I (Mac) eller Control+Shift+I (Windows, Linux).
Gå til Kilder-fanen.
Klikk Event Listener Breakpoints for å utvide menyen. DevTools avslører en liste over hendelseskategorier som animasjon og utklippstavle.
Utvid kategorien Mouse-hendelse.
Velg klikk.

Tilbake i demoen klikker du på Legg til nummer 1 og nummer 2 igjen. DevTools stopper og markerer kodelinjen i kildepanelet:

funksjon onClick() (

Når du trykker på klikk angir du et bruddpunkt basert på alle klikkhendelser. Når klikket skjer noen node og denne noden har en behandler klikk hendelser, DevTools stopper automatisk kjøringen på den første linjen med klikkbehandlerkode for denne noden.

Trinn 3: Utforsk koden

En vanlig årsak til feil er at skriptet kjøres i feil rekkefølge. Ved å undersøke koden kan du kjøre koden en linje om gangen og finne ut nøyaktig hvor den kjøres i en uventet rekkefølge. Prøv det nå:

I kildepanelet i DevTools klikker du Gå inn i neste funksjonsanrop .

Gå inn i neste funksjonsanropsknapp

Denne knappen lar deg utføre onClick()-funksjonen én linje om gangen. DevTools vil stoppe kjøringen og markere neste linje kode:

If (inputsAreEmpty()) (

Klikk nå på knappen Gå over neste funksjon.

Gå over knappen for neste funksjonsanrop

Dette forteller DevTools å utføre inputAreEmpty()-funksjonen uten å gå inn i den. Vær oppmerksom på at DevTools hopper over flere linjer med kode. Dette skjer fordi inputAreEmpty() evaluerer til false , så if-setningsblokken med kode blir ikke utført.

Dette er den grunnleggende ideen bak kodeutforskning. Hvis du ser på get-started.js-koden, vil du se at feilen sannsynligvis er et sted i updateLabel()-funksjonen. I stedet for å undersøke hver linje med kode, kan du bruke en annen type bruddpunkt for å pause koden nærmere der feilen oppstår.

Trinn 4: Angi et annet bruddpunkt

De vanligste bruddpunktene satt på kodelinjer er: når du har spesifikk streng koden du vil sette på pause. Prøv det nå:

Se på siste linje kode i updateLabel():

label.textContent = addend1 + "+" + addend2 + "=" + sum;

Til venstre for koden kan du se nummeret på denne spesifikk linje: 32. Klikk på den. DevTools vil plassere et blått ikon over nummeret. Dette betyr at det er et bruddpunkt på denne linjen. DevTools vil nå alltid pause før det.

Klikk på Gjenoppta kjøring av skript-knappen:

Knapp for gjenoppta kjøring av skript

Skriptet vil kjøre til det treffer et bruddpunkt.

Se på kodelinjene som allerede er utført i updateLabel() . DevTools gir ut verdiene til addend1, addend2 og sum.

Sumverdien ser mistenkelig ut. Det ser ut som det blir behandlet som en streng når det skal være et tall. Dette kan være årsaken til feilen vår.

Trinn 5: Sjekke variabelverdiene

En annen vanlig årsak til feil er når en variabel eller funksjon genererer andre verdier enn forventet. For å se hvordan verdier endres over tid, bruker mange utviklere console.log() , men console.log() kan være kjedelig og ineffektiv av to grunner. For det første må du kanskje redigere koden manuelt med stort beløp console.log() kaller. For det andre vet du kanskje ikke nøyaktig hvilken variabel som er knyttet til feilen, så du må kanskje logge mange variabler.

Watch Expressions er et DevTools-alternativ til console.log() . Bruk Watch Expressions til å spore verdien av variabler over tid. Som navnet antyder, er Watch Expressions ikke begrenset til bare variabler. Du kan lagre alle gyldige JavaScript-uttrykk i Watch Expression. Prøv det nå:

I Sources DevTools-panelet klikker du på Watch. Seksjonen åpnes.
Klikk på Legg til uttrykk.

Legg til uttrykk-knapp

Angi type sum.
Trykk enter. DevTools vil vise: typeof sum: "string" . Verdien til høyre for kolon er resultatet av Watch-uttrykket ditt.

Som forventet behandles sum som en streng når det skal være et tall. Dette er grunnen til feilen vår i demoen.

Mens jeg snakket med kollegene mine nylig, ble jeg overrasket over at mange av dem aldri hadde brukt nettleserens innebygde JavaScript-konsollfeilsøker i arbeidet sitt. Dessverre jobber en av dem i firmaet mitt, jeg vil ikke røpe navnet hans.
For de av dere som ennå ikke er kjent med API-nettleserkonsollen, er denne artikkelen skrevet.

Visuell feilsøking

Når du jobber med et nettsted, er feilsøking hovedsakelig avhengig av visuell oppfatning. Det er ekstremt enkelt å se feiljusterte kolonner, overlappende tekst, gjøre de nødvendige redigeringene og oppdatere siden. For PHP stopper feilmeldingen skriptet og viser problemet direkte på siden. Kort sagt: de fleste feil som kan fikses umiddelbart er enkle å se etter at siden er lastet inn.

API-konsollen er et objekt (konsoll) som kan brukes til å sende ut feilsøkingsinformasjon (den kan brukes når siden har blitt lastet inn av nettleseren). Konsollen er mest effektiv når du arbeider med JavaScript.

Feilsøking av javascript firebug Hvordan spore hendelser

Firefox - Logg hendelser

Firefox + Firebug + Firequery = Viser hendelser utløst ved hjelp av jQuery

Bremser - slå av når den ikke fungerer