Kako popraviti "Tip 'null' se ne može dodijeliti tipu" u TypeScriptu

TypeScript 7.0, objavljen 8. srpnja 2026., premjestio je kompajler na novu izvornu implementaciju, ali Microsoft kaže da port čuva semantiku provjere tipova na koju su se programeri već oslanjali. To je ovdje važno jer Type 'null' is not assignable to type ...se poznata greška i dalje u osnovi odnosi na vaš model podataka: vrijednost može biti null, dok odredišni tip kaže da možda nije.

Drugim riječima, ne postoji novi trik specifičan za TypeScript 7 koji treba naučiti. Ispravno rješenje je i dalje odlučiti jesu li nullpodaci valjani, zaštititi se od njih kada još nisu sigurni za korištenje ili osigurati namjernu rezervnu opciju. Službena najava TypeScripta 7.0 objašnjava prijelaz kompajlera, dok trenutna dokumentacija strictNullChecksa i dalje definira nulli undefinedkao zasebne tipove kada je omogućena stroga provjera null vrijednosti.

Zašto TypeScript kaže „Tip 'null' se ne može dodijeliti tipu“

Greška se pojavljuje kada se izraz može izračunati kao , nullali tip primatelja isključuje null. Minimalni primjer je:

let name: string = null;

Ako strictNullChecksje omogućeno, stringznači stvarnu vrijednost niza znakova. Ne uključuje tiho null. Kompajler stoga odbacuje dodjelu umjesto da dopusti da moguća nedostajuća vrijednost teče u kod koji pretpostavlja da su metode niza znakova sigurne.

Isključivanje strictNullChecksmože uzrokovati nestanak dijagnostike, ali također uklanja važnu klasu provjera. TypeScript-ova vlastita referenca za konfiguraciju upozorava da ignoriranje nullmože undefineddovesti do neočekivanih pogrešaka tijekom izvođenja. Za većinu održavanih aplikacija, popravljanje modela ili tijeka upravljanja sigurnije je od onemogućavanja provjere.

Odaberite ispravak na temelju onoga što null znači u vašem programu

Prije promjene sintakse, odlučite što predstavlja nedostajuća vrijednost. Najodrživije rješenje ovisi o tom odgovoru.

Ispravak 1: Uključite null u tip kada je null legitiman

Ako varijabla zaista ima stanje „još nije dostupno“ ili „bez vrijednosti“, modelirajte to stanje eksplicitno:

let name: string | null = null;

name = "Avery";

Ovo nije zaobilazno rješenje. To je točan ugovor. Srednje ime profila, neobavezni rezultat baze podataka ili odabrana stavka koja počinje prazna mogu razumno imati vrijednost null. Nakon što tip kaže string | null, nizvodni kod mora dokazati da je vrijednost niz znakova prije korištenja operacija samo s nizovima znakova.

Koristite ovaj pristup kada pozivatelji trebaju razlikovati "nema vrijednosti" od stvarne vrijednosti. Nemojte | nullrefleksno dodavati samo da biste utišali kompajler; time ćete zahtjev za rukovanje pomicati prema van.

Ispravak 2: Suzite vrijednost prije nego što je upotrijebite

Ako vrijednost koja se može nullati postane sigurna nakon provjere, neka TypeScript-ova analiza toka upravljanja suzi tip. Službeni priručnik za sužavanje pokazuje da provjere poput value !== nulluklanjanja nulliz tipa unutar zaštićene grane.

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

  console.log(text.length);
}

Nakon ranog povratka, textpoznato je da je string. Ovaj uzorak se dobro skalira jer sigurnosna provjera ostaje blizu točke u kojoj pretpostavka postaje istinita.

Koristite preciznu null provjeru kada su lažne vrijednosti valjane

Uvjet kao što je if (text)također isključuje prazne nizove jer ""je lažan. Ako je prazan niz smislen, preferira se text !== null. Ako vrijednost može biti bilo koje od nullili undefined, value != nullje sažeta JavaScript provjera koja isključuje oboje; TypeScript razumije to sužavanje kako je dokumentirano u priručniku.

Ispravak 3: Navedite zadanu vrijednost s operatorom spajanja nullish

Ako vaša poslovna logika ima stvarnu rezervu, namjerno pretvorite null vrijednost u vrijednost koja nije null:

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

Operator ??koristi desnu vrijednost samo kada je lijeva strana nullili undefined. To ga čini boljim alatom za postavljanje zadanih vrijednosti nego ||kada su vrijednosti poput "", 0ili falsevaljane i treba ih sačuvati.

Ovo rješenje je idealno za oznake, zadane postavke konfiguracije i vrijednosti samo za prikaz. Manje je prikladno kada vaš program mora znati je li vrijednost zaista nedostajala, jer rezervna opcija namjerno uklanja tu razliku.

Ispravak 4: Koristite operator tvrdnje koji nije null samo kada već imate jamstvo

Postfiks !govori TypeScriptu da tretira vrijednost kao ne-null i ne-undefined:

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

Ovo se kompajlira jer !uklanja dio koji se može nullabilno koristiti za provjeru tipa. Ne dodaje provjeru tijekom izvođenja. Ako element ne postoji, kod i dalje može propasti kada pokuša pristupiti textContent.

Koristite !samo kada neka druga invarijanta zaista jamči postojanje vrijednosti i kompajler ne može izraziti ili zaključiti tu invarijantu. Za DOM pretrage, zahtjeve za podacima, čitanje predmemorije i korisnički unos, prava provjera je obično robusnija:

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

Dobro pitanje za pregled koda je: „Što nameće ovu vrijednost tijekom izvođenja?“ Ako je odgovor samo „očekujemo to“, tvrdnja vjerojatno skriva grešku umjesto da je ispravlja.

Ispravak 5: Ispravite funkciju ili tip objekta na izvoru

Ponekad je web-mjesto za dodjelu zadataka nevino, a pravi problem je obmanjujući ugovor. Pretpostavimo da pretraga vrati rezultat nullkada ne postoji kupac:

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

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

Ako bi funkcija bila otipkana kao vraćajuća vrijednost (return only) Customer, pozivateljima bi bilo rečeno da je neuspjeh nemoguć iako implementacija kaže drugačije. Radije bi bilo ispraviti tip povrata i prisiliti pozivatelje da obrađuju nedostajući slučaj.

Isti princip vrijedi i za sučelja. Ako API polje može eksplicitno sadržavati JSON null, modelirajte ga kao field: string | null. Ako svojstvo može biti odsutno, opcionalno svojstvo kao što field?: stringje predstavlja odsutnost putem undefined, a ne eksplicitno null. Ako se pojavljuju oba oblika, modelu će možda biti potreban field?: string | null.

Ispravak 6: Koristite NonNullable za ponovno upotrebljive transformacije tipova

TypeScript uključuje globalni NonNullable<Type>uslužni program koji uklanja null`and` undefinediz tipa. Službena dokumentacija o uslužnim programima navodi ga kao standardnu ​​transformaciju tipa.

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

Ovo je korisno prilikom izvođenja tipa za validirani sloj, ali samo po sebi ne validira vrijednosti. I dalje vam je potreban tijek kontrole tijekom izvođenja kako biste dokazali da stvarna vrijednost nije null prije nego što je vratite ili proslijedite kao tip koji se ne može null-ati.

Što je s "kao nizom znakova"?

Tvrdnja tipa kao što je value as stringmože potisnuti grešku, ali ima isto osnovno ograničenje kao !: mijenja ono u što kompajler vjeruje bez provjere vrijednosti tijekom izvođenja. Prikladna je samo kada imate vanjsko znanje koje TypeScript ne može zaključiti. Ne bi trebao biti zadani odgovor na podatke koji se mogu staviti u null.

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

Ako trebate dokazati da je vrijednost niz znakova, preferirajte validaciju:

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

const safeValue: string = value;

Nemojte "popravljati" problem onemogućavanjem strictNullChecks.

S strictNullCheckspostavkom na false, TypeScript uglavnom ignorira nulli undefinedu mogućnosti dodjeljivanja. To može olakšati kompajliranje starijeg koda, ali također uklanja mogućnost kompajlera da označi mnoge putove nedostajućih vrijednosti prije izvođenja. Trenutna dokumentacija o kompatibilnosti tipova , ažurirana u rujnu 2026., još uvijek razlikuje ponašanje null vrijednosti ovisno o ovoj opciji.

Ako migrirate veliki naslijeđeni projekt, omogućavanje strožih provjera može zahtijevati postupno čišćenje. Čak i tada, onemogućavanje provjere null vrijednosti tretirajte kao ograničenje migracije, a ne kao preferirani lokalni popravak za pojedinačnu pogrešku.

Praktičan slijed za otklanjanje pogrešaka

1. Pročitajte vrstu odredišta. Ako piše string, User, ili neka druga konkretna vrsta, pitajte nulltreba li tamo doista biti dopušteno.
2. Prati gdje ulazi null. Provjerite vrstu povrata funkcije, svojstvo objekta, rezultat pretraživanja, model baze podataka/API-ja, DOM upit ili početno stanje.
3. Odaberite semantičko rješenje. Modelirajte null unijom, suzite ga, osigurajte zamjensku opciju ili ispravite izvorni ugovor.
4. Koristite tvrdnje samo za stvarne invarijante. Tvrdnja koja nije nula ili tvrdnja tipa trebala bi dokumentirati znanje koje zaista posjedujete, a ne brisati nesigurnost.
5. Ponovno pokrenite kompajler i testirajte null putanju. Čista izgradnja dokazuje da je odnos tipova prihvatljiv; test tijekom izvođenja dokazuje da vaše ponašanje nedostajuće vrijednosti zapravo odgovara zahtjevu proizvoda.

Uobičajeni primjeri i najbolji odgovor

Pretraga može propasti

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

Array.prototype.findmože vratiti undefined, pa zaštitite rezultat ili osigurajte rezervnu vrijednost. Ovo je isto rezoniranje kao i za null vrijednost iako je nedostajući tip , undefineda ne null.

Polje baze podataka ili API-ja eksplicitno vraća null

Zadržite | nulltip granice ako je to ono što vanjski ugovor zapravo šalje. Zatim pretvorite ili validirajte na granici gdje vaša aplikacija zahtijeva stvarnu vrijednost.

Varijabla počinje prazna, ali se kasnije mora popuniti

Koristite uniju koja može sadržavati null vrijednosti tijekom faze u kojoj je "nije spreman" legitimno ili restrukturirajte kod tako da konstrukcija zahtijeva vrijednost. Preferirajte drugi pristup kada potpuno inicijalizirani objekt nikada ne bi trebao postojati u djelomičnom stanju.

Zaključak

Najsigurnije rješenje za "Tip 'null' nije dodijeliv tipu" nije korištenje jednog operatora. To je odabir tipa koji odražava stvarnost, a zatim usklađivanje toka kontrole s tim tipom. Koristi se T | nullkada je null valjan, eksplicitno sužavanje kada se vrijednost mora provjeriti, ??kada postoji stvarna rezervna opcija i !samo kada postoji jamstvo izvođenja izvan TypeScriptovog prikaza.

TypeScript 7.0 mijenja arhitekturu kompajlera, a ne ovaj princip dizajna. Ako vaš kod kaže da vrijednost ne može biti null, učinite tu izjavu istinitom za vrijeme izvođenja, kao i u sustavu tipova.