li>{c} har kvadratrot: {harKvadratrot(c)}</li 37 </ul>

Prøv å legge inn de tilsvarende endringene i koden på datamaskinen din, og gjennomfør testtilfelle #1 fra kapittel 2.3.

1 <button 2 on:click={() => { 3 console.log("Navn var", navn) 4 navn = endringsforslag 5 console.log("Navn endret til", navn) 6 endrerNavn = false 7 }}

8 > 9 Lagre 10 </button>

Når du har utført testen, ser konsollen slik ut:

Linjen oppfører seg med andre ord som forventet. Variabelen navn som inneholdt verdien "Ny vare", får den nye verdien etter at du har klikket på «Lagre». Her begynte vi å mistenke at det var noe galt i måten handleliste.svelte reagerte på endringer fra Teller på. Derfor la vi inn følgende linje i slutten av script-blokken i handleliste.svelte:

Prøv å legge til denne linjen i handleliste.svelte på datamaskinen din, og gjennomfør testtilfelle #1 fra 2.4 på side XXX igjen. Noter det du observerer.

$: console.table(varer)

console.table er en variant av console.log. Forskjellen er at console. table viser dataene vi gir den, som en tabell. Det er praktisk når vi jobber med arrayer. Fordi linjen starter med $:, kjører den når en av verdiene i varer endrer seg. Altså burde vi se en melding i konsollen hver gang vi endrer antall eller navn for en av varene.

Da vi utførte testen, så loggen slik ut etter at vi hadde lagt til kaffe og epler:

Hvis vi følger med på loggen mens vi utfører testen, er det lett å se når ting går galt. Når vi har gitt et nytt navn til det første objektet i arrayet, bør vi for eksempel se en melding i konsollen, men den dukker aldri opp. Når vi deretter legger til en ny vare i listen, dukker det opp en melding som viser at det første objektet i arrayet aldri fikk en ny verdi.

Hvor tror du det er sannsynlig at feilen ligger med utgangspunkt i det vi har gjort av logging og feilsøking til nå? Hva ville ha vært ditt neste steg i feilsøkingsprosessen hvis du ikke har noen mistanke?

DISKUTER

På dette tidspunktet bestemte vi oss for å lese gjennom all koden som hadde med sammenkobling av listen og Teller-komponenten å gjøre, og da så vi fort hva feilen var. Vi hadde glemt å sette inn bind: foran egenskapen navn i Teller-komponenten. Koden var altså:

1 <Teller 2 navn={vare.navn} 3 bind:verdi={vare.antall} 4 />

Vi oppdaterte koden slik:

1 <Teller 2 bind:navn={vare.navn} 3 bind:verdi={vare.antall} 4 />

Hvis vi retter denne feilen og kjører testene på nytt, blir resultatet som forventet både for testtilfelle #1 og #2.

FEILSØKING ER SJELDEN GØY, MEN FEILEN ER SOM REGEL ENKEL

Når koding og feilsøking forklares i undervisningssammenheng, er det lett å få inntrykk av at det er en enkel og følelsesløs prosess: «Hvis X, gjør Y og Z, og vips så har du ønsket resultat.» I virkeligheten er feilsøking forbundet med en del frustrasjon. Selv de som har mange års erfaring som programmerere, blir frustrert når koden ikke virker som forventet.

Når vi oppdager årsaken til en feil, virker den ofte veldig åpenbar. Slike feil er både en lettelse og en skuffelse. Det tar kort tid å rette dem opp, men de burde jo ikke ha