I do it this way, but this led to people asking me in reviews why I use NULL^^
My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure.
Since then, I've sticked to it, and am "allowed" to use NULL ^^
It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code.
But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error.
When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)
In general the language uses `null` if it would otherwise return an object (similar to Java; this is also why null is an object but not really in both languages), while `undefined` is used if it could otherwise return any value.
Could the language have done without both null and undefined? Definitely. But it's here and here to stay.
Though, it's not the only language with two nulls. Julia has nothing and missing, though their semantics are more well defined and with different behaviors than in JavaScript.
If you're a type purist then undefined looks nicer... It'd be like being upset at booleans because things get coerced to them or some 'ish.
No: it's the type that has one inhabitant—it's not that type's fault that it appears as a default argument or var or was left out of JSON... So long as typeof null === "object", null is the absurd one
undefined is not less absurd because there are parts of the standard that allow you to differentiate between
undefined
and a non-initialized value.
Of course you shouldn't do that, but I once encountered a library that behaved differently depending on whether an option in an options bag object was not present or explicitly set to undefined.
You can run into similar ugliness with function parameters, if you do evil things like using
arguments
And of course you can explicitly check keys of objects, including parameters that are going to be destructured.
All not things you should do, but taints the "purity" argument, doesn't it? :D
My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure.
Since then, I've sticked to it, and am "allowed" to use NULL ^^
It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code.
But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error.
When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)