Kuinka korjata "Type 'null' ei ole määritettävissä tyypille" TypeScriptissä

TypeScript 7.0, joka julkaistiin 8. heinäkuuta 2026, siirsi kääntäjän uuteen natiiviin toteutukseen, mutta Microsoftin mukaan portti säilyttää kehittäjien jo aiemmin käyttämän tyyppitarkistuksen semantiikan. Tällä on tässä merkitystä, koska tuttu Type 'null' is not assignable to type ...virhe liittyy edelleen pohjimmiltaan tietomalliisi: arvo voi olla null, kun taas kohdetyyppi sanoo, ettei se välttämättä ole.

Toisin sanoen, ei ole olemassa uutta TypeScript 7 -kohtaista kikkaa, jota voisi opetella. Oikea ratkaisu on edelleen päättää, onko nulldata kelvollista, suojautua siltä, ​​kun sitä ei ole vielä turvallista käyttää, tai tarjota tarkoituksellinen vararatkaisu. Virallisessa TypeScript 7.0 -tiedotteessa selitetään kääntäjän siirtymä, kun taas nykyisessä strictNullChecks-dokumentaatiossa määritellään edelleen nullja undefinederillisinä tyyppeinä, kun tiukka null-tarkistus on käytössä.

Miksi TypeScript sanoo, että ”Tyyppiä 'null' ei voi määrittää tyypille”

Virhe ilmenee, kun lauseke voi evaluoitua arvoksi, nullmutta vastaanottava tyyppi sulkee pois null. Vähimmäisesimerkki on:

let name: string = null;

Kun arvo strictNullCheckson käytössä, stringse tarkoittaa todellista merkkijonoarvoa. Se ei sisällytä .-merkkijonoa hiljaisesti null. Kääntäjä hylkää siis sijoituksen sen sijaan, että antaisi mahdollisen puuttuvan arvon virrata koodiin, joka olettaa merkkijonometodien olevan turvallisia.

Pois kytkeminen käytöstä strictNullChecksvoi poistaa diagnostiikan, mutta se poistaa myös tärkeän tarkistusluokan. TypeScriptin oma konfigurointiohje varoittaa, että nullja :n huomiotta jättäminen undefinedvoi johtaa odottamattomiin ajonaikaisiin virheisiin. Useimmissa ylläpidetyissä sovelluksissa mallin tai ohjausvirran korjaaminen on turvallisempaa kuin tarkistuksen poistaminen käytöstä.

Valitse korjaus sen perusteella, mitä null tarkoittaa ohjelmassasi

Ennen syntaksin muuttamista, päätä, mitä puuttuva arvo edustaa. Ylläpidettävin ratkaisu riippuu tästä vastauksesta.

Korjaus 1: Sisällytä tyyppiin null, kun null on sallittu

Jos muuttujalla on todellakin tila ”ei vielä saatavilla” tai ”ei arvoa”, mallinna tämä tila eksplisiittisesti:

let name: string | null = null;

name = "Avery";

Tämä ei ole kiertotie. Se on tarkka sopimus. Profiilin toinen nimi, valinnainen tietokannan tulos tai tyhjänä alkava valittu kohde voi kohtuudella olla null-arvoinen. Kun tyyppi sanoo string | null, alavirran koodin on todistettava, että arvo on merkkijono ennen pelkkiä merkkijonoja sisältävien operaatioiden käyttöä.

Käytä tätä lähestymistapaa, kun kutsujien on erotettava "arvoa ei ole" todellisesta arvosta. Älä lisää | nullrefleksinomaisesti vain hiljentääksesi kääntäjän; se siirtää käsittelyvaatimuksen ulospäin.

Korjaus 2: Rajaa arvoa ennen käyttöä

Jos null-arvosta tulee turvallinen tarkistuksen jälkeen, anna TypeScriptin ohjausvuoanalyysin rajata tyyppiä. Virallinen rajauskäsikirja osoittaa, että tarkistukset, kuten value !== nullpoistaminen nullsuojatun haaran tyypistä.

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

  console.log(text.length);
}

Aikaisen paluun jälkeen texttiedetään olevan string. Tämä kuvio skaalautuu hyvin, koska turvatarkistus pysyy lähellä pistettä, jossa oletus tulee todeksi.

Käytä tarkkaa null-tarkistusta, kun virheelliset arvot ovat kelvollisia

Ehto, kuten , if (text)sulkee pois myös tyhjät merkkijonot, koska ""on epätosi. Jos tyhjä merkkijono on merkityksellinen, suositaan text !== null. Jos arvo voi olla joko nulltai undefined, value != nullon ytimekäs JavaScript-tarkistus, joka sulkee pois molemmat; TypeScript ymmärtää tämän rajaamisen käsikirjassa kuvatulla tavalla.

Korjaus 3: Anna oletusarvo null-koalisointioperaattorilla

Jos liiketoimintalogiikallasi on todellinen varavaihtoehto, muunna null-arvo tarkoituksella ei-null-arvoksi:

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

Operaattori ??käyttää oikeanpuoleista arvoa vain, kun vasen puoli on nulltai undefined. Tämä tekee siitä paremman oletusarvoisen työkalun kuin silloin, kun arvot , ||kuten , tai , ovat kelvollisia ja ne tulisi säilyttää.""0false

Tämä ratkaisu sopii erinomaisesti otsikoille, määritysten oletusarvoille ja vain näytettäville arvoille. Se on vähemmän sopiva silloin, kun ohjelmasi on tiedettävä, puuttuiko arvo todella, koska varamenetelmä tarkoituksella poistaa tämän eron.

Korjaus 4: Käytä ei-null-väittämäoperaattoria vain, jos sinulla on jo takuu

Jälkitunniste (postfix) !käskee TypeScriptiä käsittelemään arvoa muuna kuin null- ja ei-määrittelemättömänä:

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

Tämä käännetään, koska !se poistaa null-osan tyyppitarkistusta varten. Se ei lisää ajonaikaista tarkistusta. Jos elementtiä ei ole olemassa, koodi voi silti epäonnistua, kun se yrittää käyttää textContent.

Käytä !vain silloin, kun jokin muu invariantti todella takaa arvon olemassaolon, eikä kääntäjä voi ilmaista tai päätellä kyseistä invarianttia. DOM-hakujen, pyyntötietojen, välimuistilukujen ja käyttäjän syötteiden kohdalla todellinen tarkistus on yleensä luotettavampi:

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

Hyvä koodikatselmointikysymys on: "Mikä pakottaa tämän arvon suorituksen aikana?" Jos vastaus on vain "odotamme sitä", väite todennäköisesti piilottaa virheen sen korjaamisen sijaan.

Korjaus 5: Korjaa funktion tai objektin tyyppi lähteessä

Joskus tehtävänantopaikka on viaton ja todellinen ongelma on harhaanjohtava sopimus. Oletetaan, että haku palauttaa tuloksen, nullvaikka asiakasta ei ole olemassa:

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

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

Jos funktio tyypitettäisiin vain palauttavaksi Customer, kutsujille kerrottaisiin, että epäonnistuminen on mahdotonta, vaikka toteutus toisin sanoo. On parempi korjata paluuarvo ja pakottaa kutsujat käsittelemään puuttuva arvo.

Sama periaate pätee rajapintoihin. Jos API-kenttä voi eksplisiittisesti sisältää JSON-koodia null, mallinna se muodossa field: string | null. Jos ominaisuus voi olla poissa, valinnainen ominaisuus, kuten , field?: stringedustaa poissaoloa muodossa undefined, ei eksplisiittisesti null. Jos molemmat muodot esiintyvät, malli saattaa tarvita field?: string | null.

Korjaus 6: Käytä NonNullable-tyyppiä uudelleenkäytettäville tyyppimuunnoksille

TypeScript sisältää globaalin NonNullable<Type>apuohjelman, joka poistaa tyypistä nullja . Virallisessa utility-types-dokumentaatiossa se on listattu standardityyppimuunnoksena.undefined

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

Tämä on hyödyllistä validoidun tason tyyppiä johdettaessa, mutta se ei itsessään validoi arvoja. Tarvitset silti ajonaikaisen ohjaustyönkulun todistaaksesi, että todellinen arvo ei ole null, ennen kuin se palautetaan tai välitetään ei-null-tyyppinä.

Entä "merkkijonona"?

Tyyppiväittämä, kuten , value as stringvoi poistaa virheen, mutta sillä on sama ydinrajoitus kuin !: se muuttaa kääntäjän uskomuksia tarkistamatta ajonaikaista arvoa. Se sopii vain silloin, kun sinulla on ulkoista tietoa, jota TypeScript ei voi päätellä. Sen ei pitäisi olla oletusarvoinen vastaus tyhjäkäyrälle datalle.

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

Jos sinun on todistettava, että arvo on merkkijono, käytä mieluummin validointia:

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

const safeValue: string = value;

Älä "korjaa" ongelmaa poistamalla strictNullChecksiä käytöstä

Kun strictNullChecksarvoksi on asetettu false, TypeScript jättää pitkälti huomiotta nullja undefinedmääritettävyydessä. Tämä voi helpottaa vanhemman koodin kääntämistä, mutta se myös poistaa kääntäjältä mahdollisuuden merkitä monia puuttuvien arvojen polkuja ennen suoritusta. Nykyinen tyyppien yhteensopivuusdokumentaatio , joka päivitettiin syyskuussa 2026, erottaa edelleen null-arvojen toiminnan tästä asetuksesta riippuen.

Jos olet siirtämässä suurta vanhaa projektia, tiukempien tarkistusten käyttöönotto saattaa vaatia vaiheittaista puhdistusta. Silloinkin null-tarkistuksen poistamista käytöstä tulisi pitää siirtorajoitteena, ei yksittäisen virheen ensisijaisena paikallisena korjauksena.

Käytännön virheenkorjaussekvenssi

1. Lue kohteen tyyppi. Jos siinä lukee string, Usertai jokin muu konkreettinen tyyppi, kysy, pitäisikö nullsinne todella päästä.
2. Jäljitä kohta, johon null tulee. Tarkista funktion paluutyyppi, objektin ominaisuus, hakutulos, tietokanta-/API-malli, DOM-kysely tai alkutila.
3. Valitse semanttinen korjaus. Mallinna null-arvoa yhdisteellä, rajaa sitä, tarjoa varavaihtoehto tai korjaa lähdekoodisopimus.
4. Käytä väitteitä vain todellisille invarianteille. Ei-nollaväittämän tai tyyppiväittämän tulisi dokumentoida aidosti hallussasi olevaa tietoa, ei poistaa epävarmuutta.
5. Suorita kääntäjä uudelleen ja testaa null-polkua. Puhdas koonti todistaa, että tyyppisuhde on hyväksyttävä; ajonaikainen testi todistaa, että puuttuvan arvon käyttäytyminen todella vastaa tuotevaatimusta.

Yleisiä esimerkkejä ja paras vastaus

Haku voi epäonnistua

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

Array.prototype.findvoi palauttaa undefined, joten varjele tulos tai tarjoa varavaihtoehto. Tämä on sama päättely kuin tyhjäarvoinen arvo, vaikka puuttuva tyyppi on undefinedeikä null.

Tietokanta- tai API-kenttä palauttaa eksplisiittisesti null-arvon

Pidä | nullrajatyyppi käytössä, jos ulkoinen sopimus todella lähettää sen. Muunna tai validoi sitten rajalla, jossa sovelluksesi vaatii reaaliarvon.

Muuttuja on aluksi tyhjä, mutta se on täytettävä myöhemmin

Käytä nullable-yhdistettävää yhdistettä vaiheessa, jossa "not ready" on oikeutettu, tai muokkaa koodia niin, että rakenne vaatii arvon. Suosi toista lähestymistapaa, kun täysin alustetun objektin ei pitäisi koskaan olla osittaisessa tilassa.

Lopputulos

Turvallisin ratkaisu ongelmaan ”Tyyppiä 'null' ei voi määrittää tyypille” ei ole yhden operaattorin käyttö. Kyse on todellisuutta vastaavan tyypin valitsemisesta ja sitten ohjausvirran mukauttamisesta vastaamaan kyseistä tyyppiä. Käytä tätä, T | nullkun null on kelvollinen, rajaa eksplisiittisesti, kun arvo on tarkistettava, ??kun on olemassa todellinen varavaihtoehto ja !vain silloin, kun TypeScriptin näkymän ulkopuolella on ajonaikainen takuu.

TypeScript 7.0 muuttaa kääntäjän arkkitehtuuria, ei tätä suunnitteluperiaatetta. Jos koodisi sanoo, että arvo ei voi olla null, aseta lausekkeelle arvo true sekä suorituksen aikana että tyyppijärjestelmässä.