Kā TypeScript labot kļūdu “Type 'null' nav piešķirams tipam”

TypeScript 7.0, kas tika izlaista 2026. gada 8. jūlijā, pārvietoja kompilatoru uz jaunu vietējo ieviešanu, taču Microsoft apgalvo, ka ports saglabā tipa pārbaudes semantiku, uz kuru izstrādātāji jau paļāvās. Tas ir svarīgi šeit, jo pazīstamā Type 'null' is not assignable to type ...kļūda joprojām būtībā ir saistīta ar jūsu datu modeli: vērtība var būt null, savukārt mērķa tips norāda, ka tā var nebūt.

Citiem vārdiem sakot, nav jāapgūst neviens jauns TypeScript 7 specifisks triks. Pareizais risinājums joprojām ir izlemt, vai nulldati ir derīgi, aizsargāties pret tiem, ja tos vēl nav droši lietot, vai nodrošināt apzinātu rezerves variantu. Oficiālajā TypeScript 7.0 paziņojumā ir paskaidrota pāreja uz kompilatoru, savukārt pašreizējā strictNullChecks dokumentācijānull un joprojām tiek definēti undefinedkā atšķirīgi tipi, ja ir iespējota stingrā nulles pārbaude.

Kāpēc TypeScript saka: “Tips 'null' nav piešķirams tipam”

Kļūda rodas, ja izteiksme var tikt novērtēta kā , nullbet saņemšanas tips izslēdz null. Minimāls piemērs ir:

let name: string = null;

Ja strictNullChecksvērtība ir iespējota, stringtas nozīmē reālu virknes vērtību. Tas klusībā neietver null. Tāpēc kompilators noraida piešķiršanu, nevis ļauj iespējami trūkstošai vērtībai ieplūst kodā, kas pieņem, ka virkņu metodes ir drošas.

Izslēdzot strictNullChecksdiagnostiku, tā var pazust, taču tā arī noņem svarīgu pārbaužu klasi. TypeScript konfigurācijas atsauce brīdina, ka ignorēšana nullvar undefinedizraisīt negaidītas izpildlaika kļūdas. Lielākajai daļai uzturēto lietojumprogrammu modeļa vai vadības plūsmas labošana ir drošāka nekā pārbaudes atspējošana.

Izvēlieties labojumu, pamatojoties uz to, ko jūsu programmā nozīmē null

Pirms sintakses maiņas izlemiet, ko apzīmē trūkstošā vērtība. No šīs atbildes ir atkarīgs visvieglāk uzturējamais risinājums.

1. labojums: iekļaujiet tipu null, ja nulle ir derīga

Ja mainīgajam patiešām ir stāvoklis “vēl nav pieejams” vai “nav vērtības”, modelējiet šo stāvokli skaidri:

let name: string | null = null;

name = "Avery";

Šis nav risinājums. Tas ir precīzs līgums. Profila otrais nosaukums, neobligāts datubāzes rezultāts vai atlasītais vienums, kas sākas tukšs, var pamatoti būt nullējams. Kad tips norāda string | null, lejupējai kodam ir jāpierāda, ka vērtība ir virkne, pirms tiek izmantotas tikai virknes darbības.

Izmantojiet šo pieeju, ja izsaucējiem ir jānošķir "vērtības nav" no reālas vērtības. Nepievienojiet | nullrefleksīvi tikai tāpēc, lai apklusinātu kompilatoru; tas nobīda apstrādes prasību uz ārpusi.

2. labojums: pirms vērtības izmantošanas sašauriniet to

Ja pēc pārbaudes nullējama vērtība kļūst droša, ļaujiet TypeScript vadības plūsmas analīzei sašaurināt tipu. Oficiālā sašaurināšanas rokasgrāmata rāda, ka tādas pārbaudes kā value !== nullnoņemšana nullno tipa aizsargātajā atzarā.

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

  console.log(text.length);
}

Pēc agrīnās atgriešanās textir zināms kā string. Šis modelis labi mērogojams, jo drošības pārbaude paliek tuvu punktam, kurā pieņēmums kļūst patiess.

Izmantojiet precīzu nulles pārbaudi, ja ir derīgas kļūdainas vērtības.

Šāds nosacījums kā if (text)arī izslēdz tukšas virknes, jo ""ir nepatiess. Ja tukšai virknei ir nozīme, priekšroka dodama text !== null. Ja vērtība var būt vai null, undefinedir value != nullkodolīga JavaScript pārbaude, kas izslēdz abus; TypeScript saprot šo sašaurinājumu, kā dokumentēts rokasgrāmatā.

3. labojums: norādiet noklusējuma vērtību ar nulles apvienošanas operatoru

Ja jūsu biznesa loģikai ir reāla rezerves iespēja, apzināti pārveidojiet nullējamo vērtību par vērtību, kas nav nulle:

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

Operators ??izmanto labās puses vērtību tikai tad, ja kreisā puse ir nullvai undefined. Tas padara to par labāku noklusējuma rīku nekā ||tad, ja tādas vērtības kā "", 0vai falseir derīgas un tās būtu jāsaglabā.

Šis risinājums ir ideāli piemērots etiķetēm, konfigurācijas noklusējuma vērtībām un tikai parādāmām vērtībām. Tas ir mazāk piemērots, ja programmai ir jāzina, vai vērtība patiešām trūka, jo rezerves risinājums apzināti iznīcina šo atšķirību.

4. labojums: Izmantojiet ne-null apgalvojuma operatoru tikai tad, ja jums jau ir garantija

Postfikss !norāda TypeScript apstrādāt vērtību kā ne-null un ne-undefinētu:

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

Tas kompilējas, jo !tipa pārbaudei tiek noņemta nullējamā daļa. Tas nepievieno izpildlaika pārbaudi. Ja elements neeksistē, kods joprojām var neizdoties, mēģinot piekļūt textContent.

Izmantojiet !tikai tad, ja kāds cits invariants patiesi garantē vērtības esamību un kompilators nevar izteikt vai secināt šo invariantu. DOM meklējumiem, pieprasījumu datiem, kešatmiņas nolasījumiem un lietotāja ievadei reāla pārbaude parasti ir robustāka:

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

Labs koda pārskatīšanas jautājums ir: “Kas nodrošina šīs vērtības ieviešanu izpildes laikā?” Ja atbilde ir tikai “mēs to sagaidām”, apgalvojums, iespējams, slēpj kļūdu, nevis to labo.

5. labojums: Izlabojiet funkcijas vai objekta tipu avotā

Dažreiz piešķiršanas vietne ir nevainīga, un patiesā problēma ir maldinošs līgums. Pieņemsim, ka meklēšana atgriež rezultātu, nullja klienta nav:

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

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

Ja funkcija tiktu ierakstīta tikai kā atgriežoša Customer, izsaucējiem tiktu paziņots, ka kļūme nav iespējama, pat ja ieviešana norāda citādi. Priekšroka tiek dota atgriešanas tipa labošanai un izsaucēju piespiešanai apstrādāt trūkstošo gadījumu.

Tas pats princips attiecas uz saskarnēm. Ja API lauks var tieši saturēt JSON null, modelējiet to kā field: string | null. Ja īpašība var nebūt, tad neobligāta īpašība, piemēram, field?: stringapzīmē neesamību caur undefined, nevis tieši null. Ja rodas abas formas, modelim var būt nepieciešams field?: string | null.

6. labojums: atkārtoti lietojamām tipu transformācijām izmantojiet NonNullable

TypeScript ietver globālo utilītu, kas no tipa NonNullable<Type>noņem nullun . Oficiālajā utilītu tipu dokumentācijā tā ir norādīta kā standarta tipa transformācija.undefined

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

Tas ir noderīgi, atvasinot tipu validētam slānim, taču tas pats par sevi nevalidē vērtības. Jums joprojām ir nepieciešama izpildlaika vadības plūsma, lai pierādītu, ka faktiskā vērtība nav nulle, pirms tā tiek atgriezta vai nodota kā tips, ko nevar nullēt.

Kā ir ar “kā virkni”?

Tipa apgalvojums, piemēram, value as stringvar nomākt kļūdu, taču tam ir tāds pats pamata ierobežojums kā !: tas maina kompilatora uzskatus, nepārbaudot izpildlaika vērtību. Tas ir piemērots tikai tad, ja jums ir ārējas zināšanas, ko TypeScript nevar secināt. Tam nevajadzētu būt noklusējuma atbildei uz datiem, kurus nevar anulē.

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

Ja jums jāpierāda, ka vērtība ir virkne, dodiet priekšroku validācijai:

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

const safeValue: string = value;

Neatrisiniet problēmu, atspējojot strictNullChecks

Ja strictNullChecksiestatīts uz false, TypeScript lielākoties ignorē nullun undefinedpiešķiramības ziņā. Tas var atvieglot vecāka koda kompilēšanu, taču tas arī novērš kompilatora iespēju atzīmēt daudzus trūkstošo vērtību ceļus pirms izpildlaika. Pašreizējā tipu saderības dokumentācija , kas atjaunināta 2026. gada septembrī, joprojām nošķir nulles vērtību darbību atkarībā no šīs opcijas.

Ja migrējat lielu mantotu projektu, stingrāku pārbaužu iespējošana var prasīt pakāpenisku tīrīšanu. Pat tad nulles pārbaudes atspējošanu uztveriet kā migrācijas ierobežojumu, nevis kā vēlamo lokālo risinājumu vienai kļūdai.

Praktiska atkļūdošanas secība

1. Izlasiet galamērķa veidu. Ja tur rakstīts string, Uservai cits konkrēts veids, pajautājiet, vai nulltur tiešām vajadzētu būt atļautam.
2. Izsekojiet vietu, kur ienāk null. Pārbaudiet funkcijas atgriešanas veidu, objekta īpašību, meklēšanas rezultātu, datubāzes/API modeli, DOM vaicājumu vai sākotnējo stāvokli.
3. Izvēlieties semantisko labojumu. Modelējiet null vērtību ar apvienojumu, sašauriniet to, nodrošiniet rezerves variantu vai labojiet avota līgumu.
4. Izmantojiet apgalvojumus tikai reāliem invariantiem. Apgalvojumam, kas nav nulls, vai tipa apgalvojumam ir jādokumentē zināšanas, kas jums patiesi pieder, nevis jāizdzēš nenoteiktība.
5. Vēlreiz palaidiet kompilatoru un pārbaudiet nulles ceļu. Tīra versija pierāda, ka tipa attiecības ir pieņemamas; izpildlaika tests pierāda, ka trūkstošās vērtības uzvedība faktiski atbilst produkta prasībai.

Biežāk sastopamie piemēri un labākā atbilde

Meklēšana var neizdoties

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

Array.prototype.findvar atgriezt undefined, tāpēc sargājiet rezultātu vai norādiet rezerves variantu. Šī ir tāda pati pamatojuma metode kā nullējamai vērtībai, pat ja trūkstošais tips ir , undefinednevis null.

Datu bāzes vai API lauks skaidri atgriež null vērtību

Saglabājiet | nullrobežas tipu, ja ārējais līgums to faktiski nosūta. Pēc tam konvertējiet vai validējiet robežā, kur jūsu lietojumprogrammai ir nepieciešama reāla vērtība.

Mainīgais sākotnēji ir tukšs, bet vēlāk tas ir jāaizpilda

Fāzē, kurā ir derīga vērtība “not ready”, izmantojiet nullējamu apvienojumu vai pārstrukturējiet kodu tā, lai konstrukcijai būtu nepieciešama šī vērtība. Dodiet priekšroku otrajai pieejai, ja pilnībā inicializētam objektam nekad nevajadzētu pastāvēt daļējā stāvoklī.

Apakšējā līnija

Drošākais risinājums kļūdai “Tips 'null' nav piešķirams tipam” nav viena operatora izmantošana. Tā ir tāda tipa izvēle, kas atspoguļo realitāti, un pēc tam vadības plūsmas pielāgošana šim tipam. Izmantojiet, T | nullja null ir derīga, skaidri sašauriniet, ja vērtība ir jāpārbauda, ??​​ja pastāv reāla rezerves iespēja, un !tikai tad, ja ārpus TypeScript skata pastāv izpildlaika garantija.

TypeScript 7.0 maina kompilatora arhitektūru, nevis šo dizaina principu. Ja jūsu kods norāda, ka vērtība nevar būt nulle, padariet šo apgalvojumu par patiesu gan izpildlaikā, gan tipu sistēmā.