Similar to why you would want to have both false and 0; it is possible to have a situation in which you wish to define something as explicitly being null.
I do think it's a little weird, but it's useful to be able to say that "this key exists and its value is null" as opposed to "there is no such key".
I thought about that too, but this breaks down once you realize that setting obj.key = undefined; will mutate an object into something which is neither "the key exists and its value is null" nor "there is no such key". The difference can e.g. bite you in things that iterate over the keys of an object or function that do that internally (like deepEquals implementations).
I guess in TS2 there would now also be a difference between a field defined as key: string | null | undefined and a field defined as key?: string | null | undefined, because the first one requires setting the key to one of the values on initialization and the other one not.
It's supposed to represent intention. Since all functions in JS are variadic, there has to be a way to differentiate between a parameter not being passed and an "empty" value that is explicitly passed. Technically, you should never explicitly assign `undefined` to anything yourself, but you can propagate it.
It can be useful when calling a function and you want to say "I don't care about parameter X" when null can be an otherwise valid value for that parameter.
I've also found it useful when a function needs to indicate it failed but is in a situation where exceptions are not useful. This is code where the consumer of the function can throw its own much more useful exception or can try to recover from the function failing (eg: it can try and fix the fault). This helps people avoid using exceptions for flow control of the application and lets exceptions be truly exceptional.
Examples:
//3rd party code could dictate 'bar' be in the spot that it is
function needsUndef(foo, bar, other){
if(bar === undefined) bar = expensive_query();
//rest of code
}
needsUndef(42, cachedResultExpensiveQuery, something);
needsUndef(42, undefined, something);
and:
foo = getFromDisk(foo_path);
if(foo === undefined)
foo = getFromNetwork(last_resort);
is much nicer than:
try{
foo = getFromDisk(foo_path);
}catch(ex){
//Yes, I know you can filter exceptions, but what if someone forgets or sets too wide
//of a net?
foo = getFromNetwork(last_resort);
}
or:
if(path_isValid(foo_path) && canReadFromPath(foo_path))
foo = getFromDisk(foo_path);
else foo = getFromNetwork(last_resort);
They'd want it indirectly, because they want to use or target javascript, which has always had both. There's very little reason why someone would have a primary goal of using both.
undefined typically means it has yet to be defined whereas null means it does not have a proper value set. For example I use null where there is an exception an cannot set a variable to a sane value.
When I see null it means a value could not be set or that it was intentionally unset. undefined means it was never set in the first place.
