Sådan rettes "Type 'null' kan ikke tildeles til type" i TypeScript

TypeScript 7.0, udgivet den 8. juli 2026, flyttede compileren til en ny native implementering, men Microsoft siger, at porten bevarer den typekontrol-semantik, som udviklere allerede har stolet på. Det er vigtigt her, fordi den velkendte Type 'null' is not assignable to type ...fejl stadig fundamentalt handler om din datamodel: en værdi kan være null, mens destinationstypen angiver, at den muligvis ikke er det.

Med andre ord er der ikke noget nyt TypeScript 7-specifikt trick at lære. Den rigtige løsning er stadig at afgøre, om nuller gyldige data, beskytte sig mod dem, når de endnu ikke er sikre at bruge, eller give et bevidst fallback. Den officielle TypeScript 7.0-meddelelse forklarer compiler-overgangen, mens den nuværende strictNullChecks-dokumentation fortsat definerer nullog undefinedsom forskellige typer, når strict null-kontrol er aktiveret.

Hvorfor TypeScript siger "Typen 'null' kan ikke tildeles til en type"

Fejlen opstår, når et udtryk kan evalueres til , nullmen den modtagende type udelukker null. Et minimalt eksempel er:

let name: string = null;

Med strictNullChecksaktiveret stringbetyder det en reel strengværdi. Den inkluderer ikke lydløst null. Compileren afviser derfor tildelingen i stedet for at lade en mulig manglende værdi flyde ind i kode, der antager, at strengmetoder er sikre.

Deaktivering strictNullCheckskan få diagnosticeringen til at forsvinde, men det fjerner også en vigtig klasse af kontroller. TypeScripts egen konfigurationsreference advarer om, at ignorering nullkan undefinedføre til uventede runtime-fejl. For de fleste vedligeholdte applikationer er det sikrere at rette modellen eller kontrolflowet end at deaktivere kontrollen.

Vælg rettelsen baseret på, hvad null betyder i dit program

Før du ændrer syntaksen, skal du afgøre, hvad den manglende værdi repræsenterer. Den mest vedligeholdbare løsning afhænger af dette svar.

Rettelse 1: Inkluder null i typen, når null er legitimt

Hvis en variabel reelt har en tilstand "ikke tilgængelig endnu" eller "ingen værdi", skal denne tilstand modelleres eksplicit:

let name: string | null = null;

name = "Avery";

Dette er ikke en løsning. Det er en præcis kontrakt. En profils mellemnavn, et valgfrit databaseresultat eller et valgt element, der starter tomt, kan med rimelighed være nullable. Når typen siger string | null, skal downstream-kode bevise, at værdien er en streng, før der kan bruges streng-only-operationer.

Brug denne fremgangsmåde, når kaldere skal skelne mellem "der er ingen værdi" og en reel værdi. Tilføj ikke | nullrefleksivt blot for at lukke munden på compileren; det skubber håndteringskravet udad.

Løsning 2: Indsnævr værdien, før du bruger den

Hvis en nullværdi bliver sikker efter en kontrol, så lad TypeScripts kontrolflowanalyse indsnævre typen. Den officielle indsnævringshåndbog viser, at kontrol som f.eks. value !== nullfjerner nullfra typen inde i den beskyttede gren.

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

  console.log(text.length);
}

Efter den tidlige returnering texter kendt for at være en string. Dette mønster skalerer godt, fordi sikkerhedskontrollen forbliver tæt på det punkt, hvor antagelsen bliver sand.

Brug en præcis nulkontrol, når falske værdier er gyldige

En betingelse som f.eks if (text). ekskluderer også tomme strenge, fordi ""er falsk. Hvis en tom streng er meningsfuld, foretrækkes text !== null. Hvis værdien kan være enten nulleller undefined, value != nuller en kortfattet JavaScript-kontrol, der ekskluderer begge; TypeScript forstår denne indsnævring, som dokumenteret i håndbogen.

Rettelse 3: Angiv en standardværdi med nullish coalescing-operatoren

Hvis din forretningslogik har et reelt fallback, skal du bevidst konvertere den nullable værdi til en ikke-nullværdi:

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

Operatoren ??bruger kun værdien til højre, når venstre side er nulleller undefined. Det gør den til et bedre standardværktøj end ||når værdier som "", 0eller falseer gyldige og bør bevares.

Denne løsning er ideel til etiketter, konfigurationsstandarder og værdier, der kun vises. Den er mindre egnet, når dit program skal vide, om en værdi virkelig manglede, fordi alternativet bevidst skjuler denne sondring.

Rettelse 4: Brug kun den ikke-null assertion-operator, når du allerede har en garanti

Postfixet !fortæller TypeScript, at det skal behandle en værdi som ikke-null og ikke-udefineret:

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

Dette kompilerer fordi !`nullable` fjerner den del, der kan bruges til typekontrol. Det tilføjer ikke en runtime-kontrol. Hvis elementet ikke findes, kan koden stadig fejle, når den forsøger at tilgå ` textContent.`.

Brug !kun, når en anden invariant virkelig garanterer, at værdien eksisterer, og compileren ikke kan udtrykke eller udlede denne invariant. For DOM-opslag, anmodningsdata, cache-læsninger og brugerinput er en reel kontrol normalt mere robust:

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

Et godt spørgsmål i en kodegennemgang er: "Hvad håndhæver denne værdi under kørsel?" Hvis svaret blot er "vi forventer det", skjuler påstanden sandsynligvis en fejl i stedet for at rette en.

Rettelse 5: Ret funktionen eller objekttypen ved kilden

Nogle gange er opgavesiden uskyldig, og det virkelige problem er en vildledende kontrakt. Antag, at et opslag returnerer, nullnår der ikke findes nogen kunde:

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

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

Hvis funktionen blev skrevet som kun returning Customer, ville de kaldende få at vide, at fejl er umulig, selvom implementeringen siger andet. Det er bedre at rette returtypen og tvinge de kaldende til at håndtere det manglende tilfælde.

Det samme princip gælder for grænseflader. Hvis et API-felt eksplicit kan indeholde JSON null, modelleres det som field: string | null. Hvis en egenskab kan være fraværende, repræsenterer en valgfri egenskab, f.eks. field?: stringfravær gennem undefined, ikke eksplicit null. Hvis begge former forekommer, kan modellen have brug for field?: string | null.

Rettelse 6: Brug NonNullable til genanvendelige typetransformationer

TypeScript inkluderer det globale NonNullable<Type>værktøj, som fjerner nullog undefinedfra en type. Den officielle dokumentation for værktøjstyper angiver det som en standard typetransformation.

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

Dette er nyttigt, når man udleder en type for et valideret lag, men det validerer ikke værdier i sig selv. Du skal stadig bruge et runtime-kontrolflow til at bevise, at den faktiske værdi ikke er nul, før du returnerer eller sender den som den ikke-null-bare type.

Hvad med "som en streng"?

En typepåstand som f.eks. value as stringkan undertrykke fejlen, men den har den samme kernebegrænsning som !: den ændrer, hvad compileren mener, uden at kontrollere runtime-værdien. Den er kun passende, når du har ekstern viden, som TypeScript ikke kan udlede. Den bør ikke være standardsvaret på data, der kan nulliseres.

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

Hvis du skal bevise, at værdien er en streng, foretrækkes validering:

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

const safeValue: string = value;

"Løs" ikke problemet ved at deaktivere strictNullChecks

Med strictNullCheckssat til false, ignorerer TypeScript stort set nullog undefinedi tildelingsmuligheder. Det kan gøre ældre kode nemmere at kompilere, men det fjerner også compilerens mulighed for at markere mange stier med manglende værdier før kørsel. Den nuværende dokumentation for typekompatibilitet , opdateret i september 2026, skelner stadig mellem opførslen af ​​nullish-værdier afhængigt af denne indstilling.

Hvis du migrerer et stort ældre projekt, kan det kræve trinvis oprydning at aktivere strengere kontroller. Selv da bør du betragte deaktivering af null-kontrol som en migreringsbegrænsning, ikke som den foretrukne lokale løsning til en enkelt fejl.

En praktisk fejlfindingssekvens

1. Læs destinationstypen. Hvis der står string, User, eller en anden konkret type, så spørg om det nullvirkelig burde være tilladt der.
2. Spor hvor null indtastes. Kontroller funktionens returtype, objektegenskab, opslagsresultat, database-/API-model, DOM-forespørgsel eller starttilstand.
3. Vælg den semantiske løsning. Modellér null med en union, indsnævre den, angiv et fallback, eller ret kildekontrakten.
4. Brug kun påstande for reelle invarianter. En ikke-null-påstand eller typepåstand bør dokumentere viden, du reelt besidder, ikke slette usikkerhed.
5. Kør compileren igen, og test null-stien. En ren build beviser, at typeforholdet er acceptabelt; en runtime-test beviser, at din manglende værdi-adfærd faktisk matcher produktkravet.

Almindelige eksempler og det bedste svar

Et opslag kan mislykkes

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

Array.prototype.findkan returnere undefined, så beskyt resultatet eller angiv et fallback. Dette er den samme argumentation som en nullabel værdi, selvom den manglende type er undefinedi stedet for null.

Et database- eller API-felt returnerer eksplicit null

Behold | nullgrænsetypen, hvis det er det, den eksterne kontrakt rent faktisk sender. Konverter eller valider derefter ved den grænse, hvor din applikation kræver en reel værdi.

En variabel starter tom, men skal udfyldes senere

Brug en nullable union i den fase, hvor "ikke klar" er legitim, eller omstrukturer koden, så konstruktionen kræver værdien. Foretræk den anden tilgang, når et fuldt initialiseret objekt aldrig bør eksistere i en delvis tilstand.

Konklusion

Den sikreste løsning på "Typen 'null' kan ikke tildeles en type" er ikke en enkelt operator. Det er at vælge en type, der afspejler virkeligheden, og derefter få kontrolflowet til at matche den type. Bruges T | nullnår null er gyldigt, eksplicit indsnævring når værdien skal kontrolleres, ??når der findes et reelt fallback, og !kun når der findes en runtime-garanti uden for TypeScripts visning.

TypeScript 7.0 ændrer compilerarkitekturen, ikke dette designprincip. Hvis din kode siger, at en værdi ikke kan være null, skal du gøre denne sætning sand under kørsel såvel som i typesystemet.