Null vs. Undefined

gratis youtube-video om emnet

JavaScript (og ved utvidelse TypeScript) har to bunntyper : null og undefined. De er ment å bety forskjellige ting:

• Noe har ikke blitt initialisert: undefined.

• Noe er for øyeblikket utilgjengelig: null.

Faktum er at du må håndtere begge deler. Interessant i JavaScript med ==null og undefined er bare lik hverandre:

// Both null and undefined are only `==` to themselves and each other:
console.log(null == null); // true (of course)
console.log(undefined == undefined); // true (of course)
console.log(null == undefined); // true
// You don't have to worry about falsy values making through this check
console.log(0 == undefined); // false
console.log('' == undefined); // false
console.log(false == undefined); // false

Anbefal == null for å sjekke for begge undefinedeller null. Du vil vanligvis ikke skille mellom de to.

function foo(arg: string | null | undefined) {
 if (arg != null) {
 // arg must be a string as `!=` rules out both null and undefined. 
 }
}

Du kan også gjøre== undefined, men== nuller mer konvensjonell / kortere.

ett unntak, rotnivå undefined verdier som vi diskuterer neste.

Kontrollerer for rotnivå udefinert

Husk hvordan jeg sa at du skulle bruke == null? Selvfølgelig gjør du det (fordi jeg bare sa det^). Ikke bruk den til rotnivå ting. I streng modus hvis du bruker foo og foo er udefinert, får du etReferenceError unntak og hele anropsstakken unwinds.

du bør bruke streng modus … OG FAKTISK VIL TS-kompilatoren sette den inn for deg hvis du bruker moduler … mer om de senere i boken, slik at du ikke trenger å være eksplisitt om det 🙂

for å sjekke om en variabel er definert eller ikke på globalt nivå bruker du vanligvis typeof:

if (typeof someglobal !== 'undefined') {
 // someglobal is now safe to use
 console.log(someglobal);
}

begrens eksplisitt bruk av undefined

fordi typescript gir deg muligheten til å dokumentere strukturer separat fra verdier i stedet for ting som:

function foo(){
 // if Something
 return {a:1,b:2};
 // else
 return {a:1,b:undefined};
}

du bør bruke en type annotasjon:

function foo():{a:number,b?:number}{
 // if Something
 return {a:1,b:2};
 // else
 return {a:1};
}

Node stil tilbakeringing funksjoner (f.eks (err,somethingElse)=>{ /* something */ }) kalles vanligvis mederrsatt tilnullhvis det ikke er en feil. Du bruker vanligvis bare en truthy sjekk for dette uansett:

fs.readFile('someFile', 'utf8', (err,data) => {
 if (err) {
 // do something
 } else {
 // no error
 }
});

når du lager Dine Egne Apier, er det greit å bruke null i dette tilfellet for konsistens. I all oppriktighet for dine Egne Apier bør du se på løfter, i så fall trenger du faktisk ikke å bry deg med fraværende feilverdier (du håndterer dem med .then vs .catch).

ikke bruk undefined som et middel for å betegne gyldighet

For eksempel en forferdelig funksjon som dette:

function toInt(str: string) {
 return str ? parseInt(str) : undefined;
}

kan skrives mye bedre slik:

function toInt(str: string): { valid: boolean, int?: number } {
 const int = parseInt(str);
 if (isNaN(int)) {
 return { valid: false };
 }
 else {
 return { valid: true, int };
 }
}

json og serialisering

json-standarden har støtte for koding nullmen ikke undefined. NÅR JSON-koder et objekt med et attributt som er null, vil attributtet bli inkludert med nullverdien, mens et attributt med en undefined – verdi vil bli ekskludert helt.

JSON.stringify({willStay: null, willBeGone: undefined}); // {"willStay":null}

SOM et resultat kan json-baserte databaser støtte nullverdier, men ikke undefined verdier. Siden attributter satt til null er kodet, kan du overføre hensikten å fjerne et attributt ved å sette verdien til null før koding og overføring av objektet til en ekstern butikk.

Innstilling av attributtverdier til undefined kan spare på lagrings-og overføringskostnader, da attributtnavnene ikke blir kodet. Dette kan imidlertid komplisere semantikken for å fjerne verdier vs. fraværende verdier.

Final thoughts

TypeScript-teamet bruker ikke null: Retningslinjer For TypeScript-koding og det har ikke forårsaket noen problemer. Douglas Crockford mener null er en dårlig ide ,og vi bør alle bare bruke undefined.NodeJS stilkodebaser bruker Imidlertid null for Feilargumenter som standard som det betegner Something is currently unavailable. Jeg personlig bryr meg ikke om å skille mellom de to som de fleste prosjekter bruker biblioteker med ulike meninger og bare utelukker begge med == null.