Hogyan javítsuk ki a „Type 'null' Is Not Assignable to Type” hibát TypeScriptben?

A 2026. július 8-án kiadott TypeScript 7.0 a fordítót egy új natív implementációra állította át, de a Microsoft szerint a port megőrzi a fejlesztők által már korábban is használt típusellenőrzési szemantikát. Ez itt azért fontos, mert az ismerős Type 'null' is not assignable to type ...hiba továbbra is alapvetően az adatmodelledre vonatkozik: egy érték lehet null, míg a céltípus azt mondja, hogy lehet, hogy nem az.

Más szóval, nincs új, TypeScript 7-specifikus trükk, amit el kellene sajátítani. A helyes megoldás továbbra is az, hogy eldöntsük, nullérvényes-e az adat, védekezzünk ellene, amikor még nem biztonságos a használata, vagy szándékos tartalék megoldást biztosítsunk. A hivatalos TypeScript 7.0 bejelentés elmagyarázza a fordítóprogramra való átállást, míg a jelenlegi strictNullChecks dokumentációnull továbbra is a és típusokat definiálja undefinedkülönálló típusokként, amikor a szigorú nullellenőrzés engedélyezve van.

Miért írja ki a TypeScript, hogy „A 'null' típus nem rendelhető típushoz”

A hiba akkor jelenik meg, ha egy kifejezés kiértékelhető erre a típusra null, de a fogadó típus kizárja a értéket null. Egy minimális példa:

let name: string = null;

strictNullChecksEngedélyezett állapotban stringa valódi karakterlánc értéket jelent. Nem tartalmazza csendben nulla értéket. A fordító ezért elutasítja az értékadást ahelyett, hogy hagyná, hogy egy esetleges hiányzó érték bejusson a kódba, amely feltételezi, hogy a karakterlánc-metódusok biztonságosak.

A kikapcsolás strictNullCheckseltüntetheti a diagnosztikát, de egy fontos ellenőrzési osztályt is eltávolít. A TypeScript saját konfigurációs referenciája figyelmeztet, hogy a nullés a figyelmen kívül hagyása undefinedváratlan futásidejű hibákhoz vezethet. A legtöbb karbantartott alkalmazás esetében a modell vagy a vezérlési folyamat javítása biztonságosabb, mint az ellenőrzés letiltása.

Válaszd ki a javítást annak alapján, hogy mit jelent a null a programodban

A szintaxis megváltoztatása előtt döntsd el, hogy mit jelent a hiányzó érték. A legkönnyebben karbantartható megoldás ettől a választól függ.

1. javítás: Null beillesztése a típusba, ha a null jogos

Ha egy változó állapota valóban „még nem elérhető” vagy „nincs értéke”, modellezd explicit módon ezt az állapotot:

let name: string | null = null;

name = "Avery";

Ez nem egy kerülő megoldás. Ez egy pontos szerződés. Egy profil középső neve, egy opcionális adatbázis-eredmény vagy egy üresen kezdődő kiválasztott elem ésszerűen nullázható lehet. Ha a típus azt mondja string | null, hogy , a későbbi kódnak bizonyítania kell, hogy az érték karakterlánc, mielőtt csak karakterláncos műveleteket használna.

Ezt a megközelítést akkor használd, ha a hívóknak meg kell különböztetniük a „nincs érték” üzenetet a valós értéktől. Ne adj hozzá | nullreflexszerűen csak azért, hogy elnémítsd a fordítót; ezzel kifelé tolod a kezelési követelményt.

2. megoldás: Szűkítse az értéket használat előtt

Ha egy nullázható érték egy ellenőrzés után biztonságossá válik, akkor a TypeScript vezérlőfolyamat-elemzésével szűkítsük a típust. A hivatalos szűkítési kézikönyv azt mutatja, hogy az olyan ellenőrzések, mint value !== nullaz eltávolítás nulla védett ágon belüli típusból, azt mutatják.

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

  console.log(text.length);
}

A korai visszatérés után textismert, hogy string. Ez a minta jól skálázódik, mivel a biztonsági ellenőrzés közel marad ahhoz a ponthoz, ahol a feltételezés igazzá válik.

Használjon pontos nullellenőrzést, ha a hamis értékek érvényesek.

Egy olyan feltétel, mint például a , if (text)szintén kizárja az üres karakterláncokat, mert ""a hamis. Ha egy üres karakterlánc értelmes, akkor a előnyben részesítendő text !== null. Ha az érték lehet nullvagy undefined, value != nullegy tömör JavaScript-ellenőrzés, amely mindkettőt kizárja; a TypeScript megérti ezt a szűkítést, a kézikönyvben leírtak szerint.

3. javítás: Alapértelmezett érték megadása a nullish coaleszcing operátorral

Ha az üzleti logikádnak van valódi tartaléklehetősége, akkor szándékosan alakítsd át a nullázható értéket nem null értékké:

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

Az ??operátor csak akkor használja a jobb oldali értéket, ha a bal oldal nullvagy undefined. Ez jobb alapértelmezett eszközzé teszi, mint amikor az olyan értékek érvényesek ||, mint a "", 0, vagy , és meg kell őket őrizni.false

Ez a megoldás ideális címkék, konfigurációs alapértelmezések és csak megjelenítésre szánt értékek esetén. Kevésbé alkalmas, ha a programnak tudnia kell, hogy egy érték valóban hiányzik-e, mivel a tartalék szándékosan eltörli ezt a megkülönböztetést.

4. javítás: Csak akkor használja a nem null értékű állítási operátort, ha már van garanciája

A postfix !azt mondja a TypeScriptnek, hogy az értéket nem nullként és nem definiáltként kezelje:

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

Ez azért fordul le, mert !eltávolítja a nullázható részt a típusellenőrzéshez. Nem ad hozzá futásidejű ellenőrzést. Ha az elem nem létezik, a kód akkor is hibát okozhat, amikor megpróbálja elérni a textContent.

Csak akkor használjuk !, ha valamilyen más invariáns valóban garantálja az érték létezését, és a fordító nem tudja kifejezni vagy kikövetkeztetni ezt az invariánst. DOM-keresések, kérésadatok, gyorsítótár-olvasások és felhasználói bevitel esetén egy valódi ellenőrzés általában robusztusabb:

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

Egy jó kódellenőrzési kérdés: „Mi kényszeríti ki ezt az értéket futásidőben?” Ha a válasz csupán az, hogy „elvárjuk”, akkor az állítás valószínűleg egy hibát rejt, ahelyett, hogy kijavítana egyet.

5. javítás: Javítsa ki a függvény- vagy objektumtípust a forrásnál

Előfordul, hogy a megbízás helyszíne ártatlan, és a valódi probléma egy félrevezető szerződés. Tegyük fel, hogy egy keresés eredményt ad, nullamikor nincs ügyfél:

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

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

Ha a függvény csak visszatérési értékre lenne tipizálva Customer, a hívóknak azt mondanánk, hogy a hiba lehetetlen, annak ellenére, hogy a megvalósítás mást mond. Jobb lenne rögzíteni a visszatérési típust, és kényszeríteni a hívókat a hiányzó eset kezelésére.

Ugyanez az elv vonatkozik az interfészekre is. Ha egy API mező explicit módon tartalmazhat JSON-t null, akkor a következőképpen modellezzük field: string | null. Ha egy tulajdonság hiányozhat, egy opcionális tulajdonság, például field?: stringa egjelölésen keresztül jelöli a hiányt undefined, nem pedig explicit módon null. Ha mindkét forma előfordul, akkor a modellnek egjelölésre lehet szüksége field?: string | null.

6. javítás: NonNullable használata újrafelhasználható típustranszformációkhoz

A TypeScript tartalmazza a globális NonNullable<Type>segédprogramot, amely eltávolítja nullaz és a undefinedjeleket egy típusból. A hivatalos utility-types dokumentáció szabványos típustranszformációként sorolja fel.

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

Ez hasznos egy validált réteg típusának származtatásakor, de önmagában nem validálja az értékeket. Továbbra is szükség van egy futásidejű vezérlőfolyamatra annak bizonyítására, hogy a tényleges érték nem null, mielőtt nem nullázható típusként adnánk vissza vagy adnánk át.

Mi a helyzet a „karakterláncként” kifejezéssel?

Egy olyan típusállítás, mint a , value as stringelnyomhatja a hibát, de ugyanazokkal az alapvető korlátozásokkal rendelkezik, mint a !: a fordító által hitt értéket módosítja a futásidejű érték ellenőrzése nélkül. Csak akkor helyénvaló, ha olyan külső ismeretekkel rendelkezel, amelyeket a TypeScript nem tud kikövetkeztetni. Nem lehet az alapértelmezett válasz a nullázható adatokra.

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

Ha be kell bizonyítanod, hogy az érték karakterlánc, akkor használd az érvényesítést:

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

const safeValue: string = value;

Ne „javítsa” a problémát a strictNullChecks letiltásával

Ha strictNullChecksa értékre van állítva false, a TypeScript nagyrészt figyelmen kívül hagyja a nullés undefineda hozzárendelhetőséget. Ez megkönnyítheti a régebbi kód fordítását, de egyben eltávolítja a fordító azon képességét is, hogy számos hiányzó értékű elérési utat megjelöljön futásidő előtt. A jelenlegi, 2026 szeptemberében frissített típuskompatibilitási dokumentáció továbbra is megkülönbözteti a null értékek viselkedését ettől a beállítástól függően.

Ha egy nagyméretű, korábbi projektet migrálsz, a szigorúbb ellenőrzések engedélyezése szakaszos tisztítást igényelhet. Még ebben az esetben is a null-ellenőrzés letiltását migrációs korlátozásként kezeld, ne pedig egyetlen hiba preferált helyi javításaként.

Gyakorlati hibakeresési sorrend

1. Olvasd el az úti cél típusát.string Ha , User, vagy más konkrét típust ír , kérdezd meg, hogy nullvalóban oda kellene-e mennie.
2. Kövesse nyomon a null karakter beillesztését. Ellenőrizze a függvény visszatérési típusát, az objektum tulajdonságát, a keresési eredményt, az adatbázis/API modellt, a DOM lekérdezést vagy a kezdeti állapotot.
3. Válaszd a szemantikai megoldást. Modellezd a nullértéket egy unióval, szűkítsd le, adj meg egy tartalékot, vagy javítsd ki a forrásszerződést.
4. Csak valós invariánsokra használj állításokat. Egy nem null állításnak vagy típusállításnak a valóban birtokolt tudást kell dokumentálnia, nem pedig a bizonytalanságot eltörölnie.
5. Futtassa újra a fordítót, és tesztelje a null elérési utat. Egy tiszta build bizonyítja, hogy a típuskapcsolat elfogadható; egy futásidejű teszt pedig azt, hogy a hiányzó érték viselkedése valóban megfelel a termékkövetelménynek.

Gyakori példák és a legjobb válasz

Egy keresés sikertelen lehet

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

Array.prototype.findvisszaadhatja undefineda értéket, tehát védje az eredményt, vagy adjon meg egy tartalék opciót. Ez ugyanaz az érvelés, mint egy nullázható érték esetében, annak ellenére, hogy a hiányzó típus a , undefinednem pedig a null.

Egy adatbázis- vagy API-mező explicit módon null értéket ad vissza

Tartsa meg | nulla határtípust, ha a külső szerződés ténylegesen ezt küldi. Ezután konvertálja vagy érvényesítse azt a határt, ahol az alkalmazás valós értéket igényel.

Egy változó üresen indul, de később ki kell tölteni

Használj nullázható uniót abban a fázisban, ahol a „nincs kész” legitim, vagy alakítsd át a kódot úgy, hogy a konstrukció igényelje az értéket. A második megközelítést akkor részesítsd előnyben, ha egy teljesen inicializált objektum soha nem létezhet részleges állapotban.

A lényeg

A „'null' típus nem rendelhető típushoz” hiba legbiztonságosabb megoldása nem egyetlen operátor használata. Inkább egy olyan típus kiválasztása, amely tükrözi a valóságot, majd a vezérlési folyamat összehangolása ezzel a típussal. Akkor használjuk, T | nullha a null érvényes, explicit szűkítést, ha az értéket ellenőrizni kell, ??ha valódi tartalék létezik, és !csak akkor, ha a TypeScript nézetén kívül létezik egy futásidejű garancia.

A TypeScript 7.0 a fordító architektúráját változtatja meg, nem ezt a tervezési elvet. Ha a kódod azt mondja, hogy egy érték nem lehet null, akkor ezt az állítást futásidőben és a típusrendszerben is igazra kell állítani.