* Accessing a missing property or method results with undefined. Hope you remember the exact method names and field names of all objects in your codebase!
* Using "str".match(regex) results with null if there are no matches.
We are speaking about just null, not "null and undefined". Believe it or not, I simply do not use null in JS. Study the concept of "truthy and falsy" in JS.
> Accessing a missing property or method results with undefined. Hope you remember the exact method names and field names of all objects in your codebase!
I don't. I do however structure my code predictably, using consistent naming conventions and patterns. I hope you do realize JS existed for over 20 years before TS, and complex apps like gmaps and google docx were built entirely in JS.
> Using "str".match(regex) results with null if there are no matches.
const match = /bar/.exec("str");
if( match ){
// am only interested in what happens if foo returns a *truthy* result.
// The exact type of a falsy result is irrelevant, it either matches (truthy) or it doesn't (falsey)
}Maybe you are, but when people are talking about using TS just for the strict null checking, they typically refer to the (default-on) `strictNullChecks` config option, that is about both null and undefined.
Which is to say: whether you use null or undefined is not really relevant to the point that was being made...
You never interact with database? You're not supposed to pass undefined as NULL value.
And a variable that is waiting to be defined is very different from a value that received null as a result.
Dealing all those mixed up as falsy is a bad design.
I always assumed complex Google apps from that era were built with GWT, which would mean Java.
I'm anti-TS, but there is a meaningful difference between null and undefined. Most of the time it's enough to check for falsy values, but there are times when you will want a distinction between a missing value and a value of null.
Null, on the other hand, is not a lack of information. It's an absolute value just as much so as any number or string or array.
They're both falsey values, but so is the number zero. An item with a price of zero dollars is not the same as an item with an undefined price, nor is it the same as an item that explicitly has no price, i.e. null. You may not choose to model your data that way, but the terms are still meaningful, and your UI might have to change to reflect the different falsey values.
Most common case I could think of, would be in making a request from a server, using something like Apollo. `const [ data ] = useQuery(SomeQuery)` The data that comes from the server is undefined until you make the request, but null could be a valid response.
If a team member writes
function extractEmail(text) {
return x.match(/someregex/);
}
If you assume you can't get a null value, you might try to do further processing:
let [name, host] = extractEmail(x).split('@')
In the more common situation, you will actually save that to a database and that database will happen to accept null values by default, and then all hell will break loose in another totally distant bit of the code that naively fetches a list of emails from the table, grouped by host name. And you will have to chase down the bit of code that inserted that null in.
This is approximately what development without types looks like. When this happens to you, I hope you remember the following bit of advice: It doesn't have to be this way :) Alternatively you can start doing paranoid validation everywhere. That works too, except the nice thing about a type system is that it can properly track whether you need to do that or not (see https://github.com/spion/branded-types for one TS technique on how to do that)