Funksjoner i TypeScript: slik skriver du tydelig og trygg logikk

Funksjoner er selve arbeidsdyret i nesten alle programmeringsprosjekter. Når du går fra enkel skripting til mer seriøs utvikling, blir det avgjørende å skrive funksjoner som er både forståelige og trygge å bruke.

TypeScript gir deg ekstra verktøy til å beskrive hva funksjoner faktisk tar inn og gir tilbake. Det gjør det lettere å unngå misforståelser, feilsøke raskere og samarbeide med andre uten at alt må dokumenteres i fritekst.

Hvorfor funksjoner i TypeScript føles tryggere enn i ren JavaScript

I ren JavaScript kan en funksjon ta inn hva som helst og returnere hva som helst. Det gir frihet, men også mange muligheter for skjulte feil, spesielt når koden vokser eller flere jobber på samme prosjekt.

Med TypeScript kan du beskrive funksjonens kontrakt: hvilke typer den forventer, og hvilken type den returnerer. Kompilatoren hjelper deg så å sjekke at du faktisk bruker funksjonen riktig overalt.

Grunnform: slik deklarerer du en funksjon med typer

Dette er den vanligste måten å definere en funksjon i TypeScript:

Eksempel:

function leggSammen(a: number, b: number): number {
  return a + b;
}

Her skjer tre viktige ting: begge parameterne har typen number, funksjonen lover å returnere en number, og kompilatoren vil klage hvis du prøver å gi den en tekst eller glemmer å returnere riktig type.

Funksjonstyper: beskriv funksjoner som verdier

Noen ganger trenger du ikke bare å lage en funksjon, men også å beskrive hvilken form en funksjon skal ha. For eksempel når du lager API-er, callback-parametere eller deler opp logikk i flere små komponenter.

Du kan beskrive en funksjonstype slik:

type Kalkulator = (a: number, b: number) => number;

Deretter kan du bruke den typen på flere funksjoner:

const leggTil: Kalkulator = (a, b) => a + b;
const gang: Kalkulator = (a, b) => a * b;

Fordelen er at alle funksjoner som skal oppføre seg som en Kalkulator nå må følge samme kontrakt. Hvis en av dem plutselig begynner å returnere en tekst, får du beskjed med en gang ved kompilering.

Valgfrie parametere og standardverdier

I praksis vil du ofte ha funksjoner der noen parametere ikke alltid er nødvendig. TypeScript støtter dette med valgfrie parametere og standardverdier.

Valgfri parameter:

function hentHilsen(navn?: string): string {
  if (navn) {
    return `Hei, ${navn}`;
  }
  return "Hei";
}

navn?: string betyr at navn kan være en tekst eller undefined. TypeScript minner deg da på at du må håndtere tilfellet der den faktisk er undefined.

Standardverdi:

function beregnPris(sum: number, mvaSats: number = 0.25): number {
  return sum * (1 + mvaSats);
}

Her kan du kalle beregnPris(100), og funksjonen vil bruke 0.25 som standard. Fordelen er at kalleren slipper å gjette hva som er vanlig verdi, den ligger synlig i funksjonsdefinisjonen.

Funksjoner med objektparametere for mer lesbarhet

Funksjoner med mange parametere blir fort vanskelige å lese. En praktisk teknikk er å samle parametrene i et objekt, og så bruke type på dette objektet.

Eksempel med objektparameter:

type FiltreringsOpsjoner = {
  søk?: string;
  side: number;
  perSide: number;
};

function hentArtikler(opsjoner: FiltreringsOpsjoner) {
  const { søk, side, perSide } = opsjoner;
  // logikk her
}

Når du kaller funksjonen, blir det mye klarere hva som er hva:

hentArtikler({ søk: "typescript", side: 1, perSide: 20 });

Dette er spesielt nyttig i API-klienter, datahentere og tjenester som har mange mulige innstillinger.

Overloading: samme navn, flere signaturer

Noen ganger vil du ha en funksjon som kan kalles på flere tydelige måter, for eksempel med tekst eller tall, og du vil beskrive dette eksplisitt. Da kan du bruke funksjonsoverlasting.

Eksempel:

function tilTall(verdi: string): number;
function tilTall(verdi: number): number;
function tilTall(verdi: string | number): number {
  if (typeof verdi === "string") {
    return Number(verdi);
  }
  return verdi;
}

De øverste linjene er signaturene som andre ser, og den nederste er implementasjonen. Når du kaller tilTall, vil TypeScript vite at du alltid får et tall tilbake, og at du enten kan sende inn tekst eller tall.

Funksjoner og feilhåndtering: angi hva som faktisk skjer

Det er lett å glemme at en funksjon kan kaste unntak. TypeScript tvinger deg ikke til å merke dette, men du kan likevel beskrive det gjennom typer for å få tydeligere kontrakter.

En praktisk teknikk er å bruke en returtype som enten har resultat eller feil, i stedet for å stole på at funksjonen eventuelt kaster.

Forenklet eksempel:

type Resultat<T> = {
  ok: true;
  data: T;
} | {
  ok: false;
  feil: string;
};

function parseJSON(input: string): Resultat<unknown> {
  try {
    return { ok: true, data: JSON.parse(input) };
  } catch {
    return { ok: false, feil: "Ugyldig JSON" };
  }
}

Kalleren må nå eksplisitt sjekke ok-feltet, og det blir tydelig i koden at dette er noe som kan feile, uten skjulte kast inne i funksjonen.

Gode vaner når du designer funksjoner i TypeScript

Noen retningslinjer gjør det mye enklere å holde oversikt når prosjektet vokser:

• Gi funksjoner tydelige navn som beskriver hva de gjør, ikke hvordan de gjør det.
• La typen på parameterne speile virkeligheten, for eksempel skill mellom id: string og page: number.
• Unngå å bruke any med mindre du har en veldig god grunn, og dokumenter i så fall hvorfor.
• Foretrekk rene funksjoner som ikke endrer data utenfor seg selv, da blir de lettere å teste.
• Hvis en funksjon har for mange parametere eller gjør for mye, del den opp i mindre biter.

Ved å kombinere disse vanene med typestøtten i TypeScript får du logikk som er lettere å lese, teste og endre uten å være redd for skjulte bivirkninger.

Slik kommer du videre i ditt eget prosjekt

For å få nytte av dette i praksis, kan du velge et lite hjørne av prosjektet ditt, for eksempel en datahentende tjeneste eller en samling hjelpefunksjoner, og skrive alle funksjonene med eksplisitte typer på parametere og returverdi.

Deretter kan du gradvis innføre funksjonstyper, objektparametere og eventuelle resultat-typer der du i dag bare kaster feil. Over tid vil du oppleve at editoren hjelper deg mer aktivt, samtidig som du blir tryggere på at endringer faktisk gjør det du hadde tenkt.