Okei, her er det bare Ă„ ta et dypt pust og sette i gang.
Hva veit jeg sÄ langt?
Sammenhengen til Javascript
Du kan ikke snakke om Typescript uten Ă„ nevne javascript. Typescript er nemlig en âstrengereâ variant av javascript. Med âstrengereâ sĂ„ mener jeg at det er tydeligere regler pĂ„ hva som er greit, og hva som ikke er greit, mens med javascript er det mer flytende og dynamisk. Det kan by pĂ„ problemer dersom du skal sette deg inn i en stor mengde kode som du ikke har skrevet sjĂžl, og verdiene av en variabel endres utover i koden, uten noe sĂŠrlig godt grunnlag f. eks.
Skal sies at det sikkert finnes bedre eksempler enn akkurat det der, men det er det eneste jeg kjenner til for Ăžyeblikket.
Siden det henger sÄpass tett sammen med javascript (JS) sÄ betyr det at alt du lÊrer deg om JS vil ogsÄ hjelpe deg med Ä forstÄ Typescript. Det vil si at hvis du sliter med et problem med Typescript, men klarer ikke Ä finne svaret pÄ det, sÄ er det godt mulig at du kan finne svaret gjennom Ä sÞke pÄ lignende problemer med Javascript.
SĂŠregenheter og finurligheter
Alle kodesprÄk har sine finurligheter, og det vil vÊre lettere Ä forstÄ bakgrunnen for de finurlighetene nÄr du kjenner til historien til kodesprÄket. I javascript sitt tilfelle blei det opprinnelig brukt i veldig smÄ mengder pÄ en nettside, og siden det var sÄ smÄ mengder sÄ blei det utfÞrt ganske sakte av nettleserne pÄ den tida. Ettersom sprÄket blei mer og mer populÊrt derimot sÄ blei det brukt i stÞrre grad, som krevde en effektivisering av hvordan koden blei tolka (dynamic compilation), og hva man kunne gjÞre med det (som Ä legge til APIer). Siden javascript som et sprÄk blei designa med pÄ tanke pÄ mindre formÄl, og har nÄ vokst til Ä vÊre et sprÄk som brukes til Ä skrive applikasjoner med enorme mengder kode, sÄ er det mange finurligheter som du kan snuble over.
Funker det her a?
En av fordelene med Typescript er at du fÄr beskjed om noe funker eller ikke, mens du skriver koden din. SÄ du trenger ikke Ä lure pÄ om det kommer til Ä fungere eller ikke, fram til du faktisk kjÞrer koden. Du fÄr heller beskjed mens du skriver det. SÄvidt jeg har skjÞnt.
Her er det riktignok en forskjell mellom static checking og static type checking.
Static checking klarer jeg ikke beskrive sjÞl, men det beskrives sÄnn her:
Detecting errors in code without running it is referred to as static checking.
Static type checking derimot gir deg en melding basert pÄ verdiene (og variablene?) du har definert.
const obj = { width: 10, height: 15 };
const area = obj.width * obj.heigth;
Den koden vil lede til denne feilmeldinga:
Property 'heigth' does not exist on type '{ width: number; height: number; }'. Did you mean 'height'?
Feilmeldinga dukker altsĂ„ opp fordi selve typen av variabelen som heter obj er stavet feil â heigth i stedet for height.
Spilleregler
Siden Typescript er basert pÄ javascript sÄ betyr det at de deler samme [[syntaks|]], eller de samme spillereglene forÄsirresÄnn. Det som er grei oppfÞrsel i javascript er mer eller mindre greit i Typescript og ut fra mÄten du skriver koden din. Forskjellen derimot er at Typescript legger til noen regler om hvordan ulike typer variabler kan brukes. Som i eksempelet over, hvor det er en type verdi som er stavet feil.