Często pracując z Typescriptem przychodzi moment, w którym należy sobie zadać pytanie – chcę użyć null czy undefined? Czasami może nam się wydawać, że jest to obojętne – ale jednak różnica jest.

Podstawowa różnica

Na początek:

• undefined – coś nie zostało zainicjalizowane,
• null – coś jest aktualnie niedostępne.

Jak sprawdzić obydwie te wartości w jednej operacji? Wystarczy proste użycie:

console.log(foo == undefined);

Jak się zachowa kod w odpowiednich sytuacjach? Można zerknąć do dokumentacji.

Zamiast używać np. w swoich strukturach undefined, warto tworzyć je nullowalne. Zgodnie z przykładem z dokumentacji, zamiast sztucznego przypisywania undefined:

lepiej użyć nic (czyli null):

Node – callbacks

Jednakże w NodeJS wszędzie według konwencji jest ustawiany null. Dlatego warto trzymać się tej zasady i używać zwykłego if(err):

Oczywiście jeśli używamy np. Promise, to nie musimy się przejmować sprawdzaniem, czy error ma jakąś wartość – mamy tam then() i catch(), które sobie same z tym poradzą.

Walidacja

To, o czym warto pamiętać, to to, żeby ograniczać użycia undefined w nieodpowiednich przypadkach. Na przykład zamiast undefined:

użyć nic (czyli null):

Podsumowanie

Douglas Crockford, uznawany za guru JSa, sam powiedział, że przestał używać słowa kluczowego null. Najpierw zamienił je na używanie Object.create(), później nawet z tego zrezygnował.
Jednakże null jest używany w NodeJS do obsługi błędów i tego nie możemy zmienić.
Co należy więc zrobić? Podejść do tego rozważnie i zdecydować samemu, mając na uwadze wszystkie powyższe przykłady, własne doświadczenia i aktualny problem 🙂