4 ms·

I strongly advocate for using both BUT not propagating undefined. That is to say, use null and handle undefined. You'll need to write undefined as a potential

I strongly advocate for using both BUT not propagating undefined. That is to say, use null and handle undefined. You'll need to write undefined as a potential type for potentially undefined object members, and as such it means exactly that - undefined. For everything else there is null. A sanity check would be - undefined can only appear in a function parameter type or object member type as a union with other types, or in a === comparison. For everything else there is null.

mdtusz 6y ago
The way I always see it is that `null` is for known unknowns, and `undefined` is for unknown unknowns. Explicitly defining something as `undefined` is paradoxical and IMO should never be done. I've tried to explain this concept to some co-workers without much lasting success, but it's a pretty common concept to other languages. Undefined should basically never be used as a value directly.
mantap 6y ago
It's funny, I have a policy of the opposite. Use undefined, don't propagate null. map.get("missingKey") returns undefined. The new ?. operator returns undefined, even if you pass it null. Undefined means that you don't have to care about the difference between { foo: undefined } and { }. The only pain point is that JSON.parse() produces null, but this is relatively easy to work around. I don't find any reason to ever produce a null. I just treat it as a value that can occur when using certain APIs. If your code depends on the difference between a missing key and a missing value, probably you should be using a Map which makes that difference explicit with separate set() and delete() methods.