TypeScript Delvis Inferens: Forståelse av ufullstendig typeoppløsning

TypeScripts typesystem er et kraftig verktøy for å bygge robuste og vedlikeholdbare applikasjoner. En av nøkkelfunksjonene er typeinferens, som lar kompilatoren automatisk utlede typene til variabler og uttrykk, noe som reduserer behovet for eksplisitte typeannotasjoner. TypeScripts typeinferens er imidlertid ikke alltid perfekt. Det kan noen ganger føre til det som kalles "delvis inferens", der noen typeargumenter blir utledet mens andre forblir ukjente, noe som resulterer i ufullstendig typeoppløsning. Dette kan manifestere seg på ulike måter og krever en dypere forståelse av hvordan TypeScripts inferensalgoritme fungerer.

Hva er delvis typeinferens?

Delvis typeinferens oppstår når TypeScript kan utlede noen, men ikke alle, typeargumentene for en generisk funksjon eller type. Dette skjer ofte når man jobber med komplekse generiske typer, betingede typer, eller når typeinformasjonen ikke er umiddelbart tilgjengelig for kompilatoren. De ikke-utledede typeargumentene blir vanligvis stående som den implisitte `any`-typen, eller en mer spesifikk fallback hvis en er spesifisert via en standard typeparameter.

La oss illustrere dette med et enkelt eksempel:

            
function createPair<T, U>(first: T, second: U): [T, U] {
  return [first, second];
}

const pair1 = createPair(1, "hello"); // Utledet som [number, string]
const pair2 = createPair<number>(1, "hello"); // U utledes som string, T er eksplisitt number
const pair3 = createPair(1, {}); //Utledet som [number, {}]

            

              
                Copy
              
            
          

I det første eksempelet, `createPair(1, "hello")`, utleder TypeScript både `T` som `number` og `U` som `string` fordi den har nok informasjon fra funksjonsargumentene. I det andre eksempelet, `createPair<number>(1, "hello")`, gir vi eksplisitt typen for `T`, og TypeScript utleder `U` basert på det andre argumentet. Det tredje eksempelet demonstrerer hvordan objektliteraler uten eksplisitt typing blir utledet som `{}`.

Delvis inferens blir mer problematisk når kompilatoren ikke kan bestemme alle de nødvendige typeargumentene, noe som kan føre til potensielt usikker eller uventet oppførsel. Dette gjelder spesielt når man jobber med mer komplekse generiske typer og betingede typer.

Scenarier der delvis inferens oppstår

Her er noen vanlige situasjoner der du kan støte på delvis typeinferens:

1. Komplekse generiske typer

Når man jobber med dypt nestede eller komplekse generiske typer, kan TypeScript ha problemer med å utlede alle typeargumentene korrekt. Dette gjelder spesielt når det er avhengigheter mellom typeargumentene.

            
interface Result<T, E> {
  success: boolean;
  data?: T;
  error?: E;
}

function processResult<T, E>(result: Result<T, E>): T | E {
  if (result.success) {
    return result.data!;
  } else {
    return result.error!;
  }
}

const successResult: Result<string, Error> = { success: true, data: "Data" };
const errorResult: Result<string, Error> = { success: false, error: new Error("Something went wrong") };

const data = processResult(successResult); // Utledet som string | Error
const error = processResult(errorResult);   // Utledet som string | Error

            

              
                Copy
              
            
          

I dette eksempelet tar `processResult`-funksjonen en `Result`-type med generiske typer `T` og `E`. TypeScript utleder disse typene basert på `successResult`- og `errorResult`-variablene. Men hvis du skulle kalle `processResult` direkte med en objektliteral, er det ikke sikkert TypeScript klarer å utlede typene like nøyaktig. Tenk på en annen funksjonsdefinisjon som bruker generiske typer for å bestemme returtypen basert på argumentet.

            
function extractValue<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const myObject = { name: "Alice", age: 30 };

const nameValue = extractValue(myObject, "name"); // Utledet som string
const ageValue = extractValue(myObject, "age");   // Utledet som number

//Eksempel som viser potensiell delvis inferens med en dynamisk konstruert type
type DynamicObject = { [key: string]: any };

function processDynamic<T extends DynamicObject, K extends keyof T>(obj: T, key: K): T[K] {
    return obj[key];
}

const dynamicObj:DynamicObject = {a: 1, b: "hello"};
const result = processDynamic(dynamicObj, "a"); //resultat utledes som any, fordi DynamicObject standardiserer til any

            

              
                Copy
              
            
          

Her, hvis vi ikke gir en mer spesifikk type enn `DynamicObject`, vil inferensen falle tilbake på `any`.

2. Betingede typer

Betingede typer lar deg definere typer som avhenger av en betingelse. Selv om de er kraftige, kan de også føre til utfordringer med inferens, spesielt når betingelsen involverer generiske typer.

            
type IsString<T> = T extends string ? true : false;

function processValue<T>(value: T): IsString<T> {
  // Denne funksjonen gjør egentlig ingenting nyttig under kjøring,
  // den er kun for å illustrere typeinferens.
  return (typeof value === 'string') as IsString<T>;
}

const stringValue = processValue("hello"); // Utledet som IsString<string> (som resolverer til true)
const numberValue = processValue(123);     // Utledet som IsString<number> (som resolverer til false)

//Eksempel der funksjonsdefinisjonen ikke tillater inferens
function processValueNoInfer<T>(value: T): T extends string ? true : false {
  return (typeof value === 'string') as T extends string ? true : false;
}

const stringValueNoInfer = processValueNoInfer("hello"); // Utledet som boolean, fordi returtypen ikke er en avhengig type

            

              
                Copy
              
            
          

I det første settet med eksempler utleder TypeScript korrekt returtypen basert på inndataverdien på grunn av bruken av den generiske `IsString<T>` returtypen. I det andre settet er den betingede typen skrevet direkte, så kompilatoren beholder ikke forbindelsen mellom inndata og den betingede typen. Dette kan skje når man bruker komplekse verktøytyper fra biblioteker.

3. Standard typeparametere og `any`

Hvis en generisk typeparameter har en standardtype (f.eks., `<T = any>`), og TypeScript ikke kan utlede en mer spesifikk type, vil den falle tilbake på standarden. Dette kan noen ganger skjule problemer knyttet til ufullstendig inferens, ettersom kompilatoren ikke vil gi en feilmelding, men den resulterende typen kan være for bred (f.eks., `any`). Det er spesielt viktig å være forsiktig med standard typeparametere som standardiserer til `any`, fordi det effektivt deaktiverer typesjekking for den delen av koden din.

            
function logValue<T = any>(value: T): void {
  console.log(value);
}

logValue(123);        // T er any, så ingen typesjekking
logValue("hello");    // T er any
logValue({ a: 1 });   // T er any


function logValueTyped<T = string>(value: T): void {
  console.log(value);
}

logValueTyped(123); // Feil: Argument av typen 'number' kan ikke tilordnes parameter av typen 'string | undefined'.



            

              
                Copy
              
            
          

I det første eksempelet betyr standard typeparameteren `T = any` at enhver type kan sendes til `logValue` uten klage fra kompilatoren. Dette er potensielt farlig, da det omgår typesjekking. I det andre eksempelet er `T = string` en bedre standard, da den vil utløse typefeil når du sender en verdi som ikke er en streng til `logValueTyped`.

4. Inferens fra objektliteraler

TypeScripts inferens fra objektliteraler kan noen ganger være overraskende. Når du sender en objektliteral direkte til en funksjon, kan TypeScript utlede en smalere type enn du forventer, eller den kan ikke utlede generiske typer korrekt. Dette er fordi TypeScript prøver å være så spesifikk som mulig når den utleder typer fra objektliteraler, men dette kan noen ganger føre til ufullstendig inferens når man jobber med generiske typer.

            
interface Options<T> {
  value: T;
  label: string;
}

function processOptions<T>(options: Options<T>): void {
  console.log(options.value, options.label);
}

processOptions({ value: 123, label: "Number" }); // T utledes som number

//Eksempel der typen ikke utledes korrekt når egenskapene ikke er definert ved initialisering
function createOptions<T>(): Options<T>{
    return {value: undefined as any, label: ""}; //utleder feilaktig T som never fordi den initialiseres med undefined
}

let options = createOptions<number>(); //Options, MEN verdien kan bare settes som undefined uten feil


            

              
                Copy
              
            
          

I det første eksempelet utleder TypeScript `T` som `number` basert på `value`-egenskapen til objektliteral. Men i det andre eksempelet, ved å initialisere `value`-egenskapen til `createOptions`, utleder kompilatoren `never` siden `undefined` bare kan tilordnes `never` uten å spesifisere den generiske typen. På grunn av det blir ethvert kall til `createOptions` utledet til å ha `never` som den generiske typen, selv om du eksplisitt sender den inn. Sett alltid eksplisitt standard generiske verdier i slike tilfeller for å forhindre feilaktig typeinferens.

5. Tilbakekallingsfunksjoner og kontekstuell typing

Når man bruker tilbakekallingsfunksjoner, stoler TypeScript på kontekstuell typing for å utlede typene til tilbakekallingens parametere og returverdi. Kontekstuell typing betyr at typen til tilbakekallingen bestemmes av konteksten den brukes i. Hvis konteksten ikke gir nok informasjon, kan det hende TypeScript ikke klarer å utlede typene korrekt, noe som fører til `any` eller andre uønskede resultater. Sjekk signaturer for tilbakekallingsfunksjoner nøye for å sikre at de blir typet korrekt.

            
function mapArray<T, U>(arr: T[], callback: (item: T, index: number) => U): U[] {
  const result: U[] = [];
  for (let i = 0; i < arr.length; i++) {
    result.push(callback(arr[i], i));
  }
  return result;
}

const numbers = [1, 2, 3];
const strings = mapArray(numbers, (num, index) => `Number ${num} at index ${index}`); // T er number, U er string

//Eksempel med ufullstendig kontekst
function processItem<T>(item: T, callback: (item: T) => void) {
  callback(item);
}

processItem(1, (item) => {
  //item utledes som any hvis T ikke kan utledes utenfor tilbakekallingens virkeområde
  console.log(item.toFixed(2)); //Ingen typesikkerhet.
});

processItem<number>(1, (item) => {
    //Ved å eksplisitt sette den generiske parameteren, garanterer vi at det er et tall
    console.log(item.toFixed(2)); //Typesikkerhet
});

            

              
                Copy
              
            
          

Det første eksempelet bruker kontekstuell typing for å korrekt utlede elementet som `number` og den returnerte typen som `string`. Det andre eksempelet har en ufullstendig kontekst, så det faller tilbake på `any`.

Hvordan håndtere ufullstendig typeoppløsning

Selv om delvis inferens kan være frustrerende, finnes det flere strategier du kan bruke for å håndtere det og sikre at koden din er typesikker:

1. Eksplisitte typeannotasjoner

Den mest direkte måten å håndtere ufullstendig inferens på er å gi eksplisitte typeannotasjoner. Dette forteller TypeScript nøyaktig hvilke typer du forventer, og overstyrer inferensmekanismen. Dette er spesielt nyttig når kompilatoren utleder `any` der en mer spesifikk type er nødvendig.

            
const pair: [number, string] = createPair(1, "hello"); //Eksplisitt typeannotasjon

            

              
                Copy
              
            
          

2. Eksplisitte typeargumenter

Når du kaller generiske funksjoner, kan du eksplisitt spesifisere typeargumentene ved hjelp av vinkelparenteser (`<T, U>`). Dette er nyttig når du vil kontrollere typene som brukes og forhindre at TypeScript utleder feil typer.

            
const pair = createPair<number, string>(1, "hello"); //Eksplisitte typeargumenter

            

              
                Copy
              
            
          

3. Refaktorering av generiske typer

Noen ganger kan strukturen til de generiske typene dine i seg selv gjøre inferens vanskelig. Å refaktorere typene dine for å være enklere eller mer eksplisitte kan forbedre inferens.

            
//Original, vanskelig-å-utlede type
type ComplexType<A, B, C> = {
  a: A;
  b: (a: A) => B;
  c: (b: B) => C;
};

//Refaktorert, enklere-å-utlede type
interface AType {value: string};
interface BType {data: number};
interface CType {success: boolean};

type SimplerType = {
  a: AType;
  b: (a: AType) => BType;
  c: (b: BType) => CType;
};



            

              
                Copy
              
            
          

4. Bruk av typepåstander (Type Assertions)

Typepåstander lar deg fortelle kompilatoren at du vet mer om typen til et uttrykk enn den gjør. Bruk disse med forsiktighet, da de kan skjule feil hvis de brukes feil. De er imidlertid nyttige i situasjoner der du er sikker på typen og TypeScript ikke klarer å utlede den.

            
const value: any = getValueFromSomewhere(); //Anta at getValueFromSomewhere returnerer any
const numberValue = value as number; //Typepåstand
console.log(numberValue.toFixed(2)); //Nå behandler kompilatoren verdien som et tall

            

              
                Copy
              
            
          

5. Bruk av verktøytyper (Utility Types)

TypeScript tilbyr en rekke innebygde verktøytyper som kan hjelpe med typemanipulering og inferens. Typer som `Partial`, `Required`, `Readonly` og `Pick` kan brukes til å lage nye typer basert på eksisterende, og forbedrer ofte inferens i prosessen.

            
interface User {
  id: number;
  name: string;
  email?: string;
}

//Gjør alle egenskaper påkrevde
type RequiredUser = Required<User>;

function createUser(user: RequiredUser): void {
  console.log(user.id, user.name, user.email);
}

createUser({ id: 1, name: "John", email: "john@example.com" }); //Ingen feil

//Eksempel som bruker Pick for å velge et utvalg av egenskaper
type NameAndEmail = Pick<User, 'name' | 'email'>;

function displayDetails(details: NameAndEmail){
    console.log(details.name, details.email);
}

displayDetails({name: "Alice", email: "test@test.com"});

            

              
                Copy
              
            
          

6. Vurder alternativer til `any`

Selv om `any` kan være fristende som en rask løsning, deaktiverer det effektivt typesjekking og kan føre til kjøretidsfeil. Prøv å unngå å bruke `any` så mye som mulig. Utforsk i stedet alternativer som `unknown`, som tvinger deg til å utføre typesjekker før du bruker verdien, eller mer spesifikke typeannotasjoner.

            
let unknownValue: unknown = getValueFromSomewhere();

if (typeof unknownValue === 'number') {
  console.log(unknownValue.toFixed(2)); //Typesjekk før bruk
}

            

              
                Copy
              
            
          

7. Bruk av typevakter (Type Guards)

Typevakter er funksjoner som snevrer inn typen til en variabel innenfor et spesifikt virkeområde. De er spesielt nyttige når man jobber med union-typer eller når du trenger å utføre typesjekking under kjøring. TypeScript gjenkjenner typevakter og bruker dem til å forbedre typene til variabler innenfor det beskyttede virkeområdet.

            
type StringOrNumber = string | number;

function processValueWithTypeGuard(value: StringOrNumber): void {
  if (typeof value === 'string') {
    console.log(value.toUpperCase()); //TypeScript vet at verdien er en streng her
  } else {
    console.log(value.toFixed(2));    //TypeScript vet at verdien er et tall her
  }
}

            

              
                Copy
              
            
          

Beste praksis for å unngå problemer med delvis inferens

Her er noen generelle beste praksiser du kan følge for å minimere risikoen for å støte på problemer med delvis inferens:

• Vær eksplisitt med typene dine: Ikke stol utelukkende på inferens, spesielt i komplekse scenarier. Å gi eksplisitte typeannotasjoner kan hjelpe kompilatoren med å forstå intensjonene dine og forhindre uventede typefeil.
• Hold de generiske typene dine enkle: Unngå dypt nestede eller altfor komplekse generiske typer, da de kan gjøre inferens vanskeligere. Bryt ned komplekse typer i mindre, mer håndterbare deler.
• Test koden din grundig: Skriv enhetstester for å verifisere at koden din oppfører seg som forventet med forskjellige typer. Vær spesielt oppmerksom på ytterpunkter og scenarier der inferens kan være problematisk.
• Bruk en streng TypeScript-konfigurasjon: Aktiver strenge modus-alternativer i `tsconfig.json`-filen din, som `strictNullChecks`, `noImplicitAny` og `strictFunctionTypes`. Disse alternativene vil hjelpe deg med å fange potensielle typefeil tidlig.
• Forstå TypeScripts inferensregler: Gjør deg kjent med hvordan TypeScripts inferensalgoritme fungerer. Dette vil hjelpe deg med å forutse potensielle inferensproblemer og skrive kode som er enklere for kompilatoren å forstå.
• Refaktorer for klarhet: Hvis du sliter med typeinferens, bør du vurdere å refaktorere koden din for å gjøre typene mer eksplisitte. Noen ganger kan en liten endring i kodestrukturen forbedre typeinferens betydelig.

Konklusjon

Delvis typeinferens er en subtil, men viktig del av TypeScripts typesystem. Ved å forstå hvordan det fungerer og i hvilke scenarier det kan oppstå, kan du skrive mer robust og vedlikeholdbar kode. Ved å bruke strategier som eksplisitte typeannotasjoner, refaktorering av generiske typer og bruk av typevakter, kan du effektivt håndtere ufullstendig typeoppløsning og sikre at TypeScript-koden din er så typesikker som mulig. Husk å være oppmerksom på potensielle inferensproblemer når du jobber med komplekse generiske typer, betingede typer og objektliteraler. Omfavn kraften i TypeScripts typesystem, og bruk den til å bygge pålitelige og skalerbare applikasjoner.