Slik fikser du «Typen 'null' kan ikke tilordnes til type» i TypeScript

TypeScript 7.0, utgitt 8. juli 2026, flyttet kompilatoren til en ny, innebygd implementering, men Microsoft sier at porteringen bevarer semantikken for typekontroll som utviklere allerede stolte på. Det er viktig her fordi den kjente Type 'null' is not assignable to type ...feilen fortsatt fundamentalt handler om datamodellen din: en verdi kan være null, mens destinasjonstypen sier at den kanskje ikke er det.

Med andre ord finnes det ikke noe nytt TypeScript 7-spesifikt triks å lære. Den riktige løsningen er fortsatt å avgjøre om nuller gyldige data, beskytte seg mot det når det ennå ikke er trygt å bruke, eller tilby en bevisst reserve. Den offisielle TypeScript 7.0-kunngjøringen forklarer kompilatorovergangen, mens den nåværende strictNullChecks-dokumentasjonen fortsetter å definere nullog undefinedsom distinkte typer når streng nullkontroll er aktivert.

Hvorfor TypeScript sier at «Typen 'null' kan ikke tilordnes til en type»

Feilen oppstår når et uttrykk kan evalueres til , nullmen den mottakende typen ekskluderer null. Et minimalt eksempel er:

let name: string = null;

Med strictNullChecksaktivert stringbetyr det en reell strengverdi. Den inkluderer ikke i stillhet null. Kompilatoren avviser derfor tildelingen i stedet for å la en mulig manglende verdi flyte inn i kode som antar at strengmetoder er trygge.

Å slå av strictNullCheckskan føre til at diagnostikken forsvinner, men det fjerner også en viktig klasse med kontroller. TypeScripts egen konfigurasjonsreferanse advarer om at ignorering nullkan undefinedføre til uventede kjøretidsfeil. For de fleste vedlikeholdte applikasjoner er det tryggere å fikse modellen eller kontrollflyten enn å deaktivere sjekken.

Velg løsningen basert på hva null betyr i programmet ditt

Før du endrer syntaksen, bør du bestemme hva den manglende verdien representerer. Den mest vedlikeholdbare løsningen avhenger av det svaret.

Fiks 1: Inkluder null i typen når null er legitimt

Hvis en variabel virkelig har en tilstand som er «ikke tilgjengelig ennå» eller «ingen verdi», modeller den tilstanden eksplisitt:

let name: string | null = null;

name = "Avery";

Dette er ikke en midlertidig løsning. Det er en nøyaktig kontrakt. Mellomnavnet til en profil, et valgfritt databaseresultat eller et valgt element som starter tomt, kan med rimelighet være nullverdig. Når typen sier string | null, må nedstrømskoden bevise at verdien er en streng før strengoperasjoner brukes.

Bruk denne tilnærmingen når kallere trenger å skille mellom «det finnes ingen verdi» og en reell verdi. Ikke legg til | nullrefleksivt bare for å dempe kompilatoren; dette skyver håndteringskravet utover.

Fiks 2: Begrens verdien før du bruker den

Hvis en nullverdi blir sikker etter en sjekk, la TypeScripts kontrollflytanalyse innsnevre typen. Den offisielle innsnevringshåndboken viser at sjekker som value !== nullfjerner nullfra typen inne i den beskyttede grenen.

function printLength(text: string | null) {
  if (text === null) {
    console.log("No text");
    return;
  }

  console.log(text.length);
}

Etter den tidlige returen texter kjent for å være en string. Dette mønsteret skalerer godt fordi sikkerhetssjekken holder seg nær punktet der antagelsen blir sann.

Bruk en presis nullkontroll når falske verdier er gyldige

En betingelse som if (text)ekskluderer også tomme strenger fordi ""er usann. Hvis en tom streng er meningsfull, foretrekker man text !== null. Hvis verdien kan være enten nulleller undefined, value != nuller en konsis JavaScript-sjekk som ekskluderer begge; TypeScript forstår den innsnevringen som dokumentert i håndboken.

Fiks 3: Oppgi en standardverdi med nullish-koaleseringsoperatoren

Hvis forretningslogikken din har en reell reserveverdi, konverter den nullbare verdien til en ikke-nullverdi med vilje:

const rawName: string | null = getDisplayName();
const displayName: string = rawName ?? "Guest";

Operatoren ??bruker bare verdien på høyre side når venstre side er nulleller undefined. Det gjør den til et bedre standardverktøy enn ||når verdier som "", 0eller falseer gyldige og bør bevares.

Denne løsningen er ideell for etiketter, konfigurasjonsstandarder og verdier som bare vises. Den er mindre egnet når programmet må vite om en verdi virkelig manglet, fordi reserveløsningen med vilje skjuler dette skillet.

Fiks 4: Bruk ikke-null-påstandsoperatoren bare når du allerede har en garanti

Postfixet !forteller TypeScript at det skal behandle en verdi som ikke-null og ikke-udefinert:

const element = document.getElementById("status");
element!.textContent = "Ready";

Dette kompilerer fordi !fjerner den nullbare delen for typesjekk. Det legger ikke til en kjøretidssjekk. Hvis elementet ikke finnes, kan koden fortsatt mislykkes når den prøver å få tilgang til textContent.

Brukes !kun når en annen invariant virkelig garanterer at verdien eksisterer, og kompilatoren ikke kan uttrykke eller utlede denne invarianten. For DOM-oppslag, forespørselsdata, hurtigbufferlesninger og brukerinput er en reell sjekk vanligvis mer robust:

const element = document.getElementById("status");
if (element) {
  element.textContent = "Ready";
}

Et godt spørsmål i en kodegjennomgang er: «Hva håndhever denne verdien under kjøring?» Hvis svaret bare er «vi forventer det», skjuler påstanden sannsynligvis en feil i stedet for å fikse en.

Fiks 5: Korriger funksjonen eller objekttypen ved kilden

Noen ganger er oppdragssiden uskyldig, og det virkelige problemet er en misvisende kontrakt. Anta at et søk returnerer nullnår ingen kunde finnes:

type Customer = { id: string; name: string };

function findCustomer(id: string): Customer | null {
  // Return a customer when found; otherwise return null.
  return null;
}

Hvis funksjonen ble skrevet som bare returning Customer, ville innringere bli fortalt at feil er umulig selv om implementeringen sier noe annet. Det er bedre å fikse returtypen og tvinge innringere til å håndtere det manglende tilfellet.

Det samme prinsippet gjelder for grensesnitt. Hvis et API-felt eksplisitt kan inneholde JSON null, modeller det som field: string | null. Hvis en egenskap kan være fraværende, representerer en valgfri egenskap som field?: stringfravær gjennom undefined, ikke eksplisitt null. Hvis begge formene forekommer, kan modellen trenge field?: string | null.

Fiks 6: Bruk NonNullable for gjenbrukbare typetransformasjoner

TypeScript inkluderer det globale NonNullable<Type>verktøyet, som fjerner nullog undefinedfra en type. Den offisielle dokumentasjonen for verktøytyper viser det som en standard typetransformasjon.

type MaybeName = string | null | undefined;
type Name = NonNullable<MaybeName>; // string

Dette er nyttig når du utleder en type for et validert lag, men det validerer ikke verdier i seg selv. Du trenger fortsatt en kjøretidskontrollflyt for å bevise at den faktiske verdien ikke er null før du returnerer eller sender den som den ikke-nullbare typen.

Hva med «som en streng»?

En typepåstand som value as stringkan undertrykke feilen, men den har samme kjernebegrensning som !: den endrer hva kompilatoren mener uten å sjekke kjøretidsverdien. Det er bare passende når du har ekstern kunnskap som TypeScript ikke kan utlede. Det bør ikke være standardresponsen på nullbare data.

const value: string | null = getValue();
const forced = value as string; // Compiles, but may still be null at runtime

Hvis du trenger å bevise at verdien er en streng, foretrekk validering:

const value: string | null = getValue();
if (typeof value !== "string") {
  throw new Error("Expected a string");
}

const safeValue: string = value;

Ikke «fiks» problemet ved å deaktivere strictNullChecks

Med strictNullCheckssatt til false, ignorerer TypeScript i stor grad nullog undefinedi tildelingsmuligheter. Det kan gjøre eldre kode enklere å kompilere, men det fjerner også kompilatorens mulighet til å flagge mange stier med manglende verdier før kjøretid. Den nåværende dokumentasjonen for typekompatibilitet , oppdatert i september 2026, skiller fortsatt oppførselen til nullverdier avhengig av dette alternativet.

Hvis du migrerer et stort eldre prosjekt, kan det kreve trinnvis opprydding å aktivere strengere kontroller. Selv da bør du behandle deaktivering av nullkontroll som en migreringsbegrensning, ikke som den foretrukne lokale løsningen for en enkelt feil.

En praktisk feilsøkingssekvens

1. Les destinasjonstypen. Hvis det står string, User, eller en annen konkret type, spør om det nullvirkelig burde være tillatt der.
2. Spor hvor null kommer inn. Sjekk funksjonens returtype, objektegenskap, oppslagsresultat, database-/API-modell, DOM-spørring eller starttilstand.
3. Velg den semantiske løsningen. Modeller null med en union, avgrens den, gi et alternativ eller korriger kildekontrakten.
4. Bruk kun påstander for reelle invarianter. En ikke-null-påstand eller typepåstand bør dokumentere kunnskap du virkelig besitter, ikke slette usikkerhet.
5. Kjør kompilatoren på nytt og test nullbanen. En ren bygging beviser at typeforholdet er akseptabelt; en kjøretidstest beviser at manglende verdi-oppførsel faktisk samsvarer med produktkravet.

Vanlige eksempler og det beste svaret

Et oppslag kan mislykkes

const user = users.find(u => u.id === id);

Array.prototype.findkan returnere undefined, så beskytt resultatet eller gi en reserveverdi. Dette er samme resonnement som en nullverdi selv om den manglende typen er undefinedi stedet for null.

Et database- eller API-felt returnerer eksplisitt null

Behold | nullgrensetypen hvis det er det den eksterne kontrakten faktisk sender. Konverter eller valider deretter ved grensen der applikasjonen din krever en reell verdi.

En variabel starter tom, men må fylles ut senere

Bruk en nullbar union i fasen der «ikke klar» er legitim, eller omstrukturer koden slik at konstruksjonen krever verdien. Foretrekk den andre tilnærmingen når et fullstendig initialisert objekt aldri skal eksistere i en delvis tilstand.

Konklusjon

Den sikreste løsningen for «Typen 'null' kan ikke tilordnes til type» er ikke en enkelt operator. Det handler om å velge en type som gjenspeiler virkeligheten og deretter få kontrollflyten til å samsvare med den typen. Brukes T | nullnår null er gyldig, eksplisitt innsnevring når verdien må kontrolleres, ??når en reell reserve finnes, og !bare når en kjøretidsgaranti finnes utenfor TypeScripts visning.

TypeScript 7.0 endrer kompilatorarkitekturen, ikke dette designprinsippet. Hvis koden din sier at en verdi ikke kan være null, må du gjøre den setningen sann både under kjøring og i typesystemet.