4 ms·

> You can't avoid null and undefined We are speaking about just null, not "null and undefined". Believe it or not, I simply do not use null in JS. Study the co

> You can't avoid null and undefined 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) }

Vinnl 6y ago
> We are speaking about just null, not "null and undefined". 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.
- orange8 6y ago
  My point is I never use null or worry about "strict null checking" or even what that is in the first place or even how it is configured.
  - Vinnl 6y ago
    Well, good for you, bit you can run into the exact same problems with undefined (which you do use), and TypeScript still helps with those in the exact same way. Which is to say: whether you use null or undefined is not really relevant to the point that was being made...
    - orange8 6y ago
      Thank you. I use undefined very rarely, usually with a hacky looking: "typeof foo === 'undefined'". I'd still rather just type that though than having to setup up TS. Don't get me wrong, TS is great for the eco-system, for examples it powers the intellisense behind vscode which I use daily. I just do not need to use it directly, so good for me indeed.
  - spion 6y ago
    Next time you get a "Cannot read property <x> of undefined" error at runtime, take a moment to trace why it happened, then read https://shinesolutions.com/2017/01/06/writing-safer-code-with-typescript-strict-null-checks-type-guards/ https://shinesolutions.com/2017/01/06/writing-safer-code-wit...
mekster 6y ago
null and undefined are very different. Not sure how you leave null out of your code. 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.
- orange8 6y ago
  I've already mentioned this above, please look up falsy and truthy values in JS. Null, false, 0, undefined and "" can be treated pretty much the same in 99% of your JS code. JS is after-all still a dynamic language, and there is nothing stopping you from making use of its dynamic features.
bobisme 6y ago
> complex apps like gmaps and Google docs were written entirely in JS I always assumed complex Google apps from that era were built with GWT, which would mean Java.
- Zacru 6y ago
  No, but they were written using the Closure Compiler type annotations. So closer to TS than plain JS.
  - orange8 6y ago
    Closure compiler was released in 2009, google maps in 2005. So no, you've got it all wrong. The only thing limiting you from using the full power of JS is your mindset. And Google maps is just one example, others include nodejs, electron, react, vue, svelte....
schwartzworld 6y ago
> 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. 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. https://i.stack.imgur.com/T9M2J.png https://i.stack.imgur.com/T9M2J.png
- orange8 6y ago
  Do you have a concrete example of such a time?
  - schwartzworld 6y ago
    Undefined represents the absence of information altogether. In JavaScript any key can be called on any object and if it doesn't exist it will return undefined. If you put a typo in the key name, you get undefined. If you've never set it, you get undefined. 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.
spion 6y ago
If you forget to do the check, you will get a falsy value. Hope you remember to do it every single time, and hope all your team members remember! If a team member writes function extractEmail(text) { return x.match(/someregex/); } and you call extractEmail(x), you might get a null value. If you assume you can't get a null value, you might try to do further processing: let [name, host] = extractEmail(x).split('@') and get a type error thrown. That is, if you're lucky. 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 https://github.com/spion/branded-types for one TS technique on how to do that)

Vinnl 6y ago

> We are speaking about just null, not "null and undefined". 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.

orange8 6y ago
My point is I never use null or worry about "strict null checking" or even what that is in the first place or even how it is configured.
- Vinnl 6y ago
  Well, good for you, bit you can run into the exact same problems with undefined (which you do use), and TypeScript still helps with those in the exact same way. Which is to say: whether you use null or undefined is not really relevant to the point that was being made...
  - orange8 6y ago
    Thank you. I use undefined very rarely, usually with a hacky looking: "typeof foo === 'undefined'". I'd still rather just type that though than having to setup up TS. Don't get me wrong, TS is great for the eco-system, for examples it powers the intellisense behind vscode which I use daily. I just do not need to use it directly, so good for me indeed.
- spion 6y ago
  Next time you get a "Cannot read property <x> of undefined" error at runtime, take a moment to trace why it happened, then read https://shinesolutions.com/2017/01/06/writing-safer-code-with-typescript-strict-null-checks-type-guards/ https://shinesolutions.com/2017/01/06/writing-safer-code-wit...

mekster 6y ago

null and undefined are very different. Not sure how you leave null out of your code. 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.

orange8 6y ago
I've already mentioned this above, please look up falsy and truthy values in JS. Null, false, 0, undefined and "" can be treated pretty much the same in 99% of your JS code. JS is after-all still a dynamic language, and there is nothing stopping you from making use of its dynamic features.

bobisme 6y ago

> complex apps like gmaps and Google docs were written entirely in JS I always assumed complex Google apps from that era were built with GWT, which would mean Java.

Zacru 6y ago
No, but they were written using the Closure Compiler type annotations. So closer to TS than plain JS.
- orange8 6y ago
  Closure compiler was released in 2009, google maps in 2005. So no, you've got it all wrong. The only thing limiting you from using the full power of JS is your mindset. And Google maps is just one example, others include nodejs, electron, react, vue, svelte....

schwartzworld 6y ago

> 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. 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. https://i.stack.imgur.com/T9M2J.png https://i.stack.imgur.com/T9M2J.png

orange8 6y ago
Do you have a concrete example of such a time?
- schwartzworld 6y ago
  Undefined represents the absence of information altogether. In JavaScript any key can be called on any object and if it doesn't exist it will return undefined. If you put a typo in the key name, you get undefined. If you've never set it, you get undefined. 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.

spion 6y ago

If you forget to do the check, you will get a falsy value. Hope you remember to do it every single time, and hope all your team members remember! If a team member writes function extractEmail(text) { return x.match(/someregex/); } and you call extractEmail(x), you might get a null value. If you assume you can't get a null value, you might try to do further processing: let [name, host] = extractEmail(x).split('@') and get a type error thrown. That is, if you're lucky. 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 https://github.com/spion/branded-types for one TS technique on how to do that)