Null vs. Odefinierad

gratis youtube-video om ämnet

JavaScript (och i förlängningen TypeScript) har två bottentyper:null ochundefined. De är avsedda att betyda olika saker:

  • något har inte initierats: undefined.

  • något är inte tillgängligt för tillfället: null.

faktum är att du måste hantera båda. Intressant i JavaScript med ==null och undefined är bara lika med varandra:

// 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

rekommendera == null för att kontrollera både undefined eller null. Du vill i allmänhet inte göra skillnad mellan de två.

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

Du kan också göra == undefined, men == null är mer konventionell/kortare.

ett undantag, rotnivå undefined värden som vi diskuterar nästa.

söker efter rotnivå odefinierad

Kom ihåg hur jag sa att du skulle använda == null? Självklart gör du det (för jag sa det bara ^). Använd den inte för saker på rotnivå. I strikt läge om du använder foo och foo är odefinierad får du ett ReferenceError undantag och hela samtalsstacken avvecklas.

Du bör använda strikt läge … och i själva verket kommer TS-kompilatorn att infoga den åt dig om du använder moduler … mer om dem senare i boken så att du inte behöver vara explicit om det 🙂

så för att kontrollera om en variabel är definierad eller inte på global nivå använder du normalt typeof:

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

begränsa explicit användning av odefinierad

eftersom TypeScript ger Dig möjlighet att dokumentera dina strukturer separat från värden i stället för saker som:

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

Du bör använda en typ anteckning:

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

node style callbacks

Node style callback-funktioner (t.ex. (err,somethingElse)=>{ /* something */ }) kallas vanligtvis med err inställd på null om det inte finns något fel. Du brukar bara använda en truthy check för detta ändå:

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

När du skapar dina egna API: er är det okej att använda null I detta fall för konsistens. I all uppriktighet för dina egna API: er bör du titta på löften, i så fall behöver du faktiskt inte bry dig om frånvarande felvärden (du hanterar dem med .then vs. .catch).

använd inte odefinierad som ett medel för att beteckna giltighet

till exempel en hemsk funktion så här:

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

kan skrivas mycket bättre så här:

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

JSON och serialisering

JSON-standarden har stöd för kodning null men inte undefined. När JSON-kodar ett objekt med ett attribut som är null, kommer attributet att inkluderas med dess null-värde, medan ett attribut med ett undefined värde kommer att uteslutas helt.

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

som ett resultat kan JSON-baserade databaser stödja null värden men inte undefined värden. Eftersom attribut som är inställda på null är kodade kan du överföra avsikten att rensa ett attribut genom att ställa in dess värde till null innan du kodar och överför objektet till en fjärrbutik.

Inställning av attributvärden till odefinierad kan spara på lagrings-och överföringskostnader, eftersom attributnamnen inte kodas. Detta kan dock komplicera semantiken för clearingvärden kontra frånvarande värden.

slutliga tankar

TypeScript-teamet använder inte null: TypeScript-kodningsriktlinjer och det har inte orsakat några problem. Douglas Crockford tycker nullär en dålig IDE och vi borde alla bara använda undefined.

NodeJS stilkodbaser använder emellertid null för Felargument som standard eftersom det betecknar Something is currently unavailable. Jag bryr mig inte om att skilja mellan de två eftersom de flesta projekt använder bibliotek med olika åsikter och bara utesluter båda med == null.



Lämna ett svar

Din e-postadress kommer inte publiceras.