Great video! Another use for the 'never' type is as the return type of functions that will always throw (e.g. exception helper functions). This lets the IDE detect any code after the function call as unreachable.
I’m a hard man to please when it comes to developed TH-cam channels. I’ve seen it and done it all. I’ve got to say though that your content and the way it’s presented is vastly superior to a lot of channels that had exponential growth.
The colour grading of those video makes me so happy, the iconic face of Andrew even more and the quintessence of all that being about typescript is making me feel so privilege and lucky to exist in a univers where it is possible to witness any of this
You're killing it with these videos, Andrew! I think what many tech videos about languages miss is pragmatism and usage, after all anyone can read the docs and figure out syntax. However you've found a balance between theory and pragmatism.
3:52 i would have mentioned that you probably wouldn't want to write a lot of this kind of manual object parsing code. it gets very messy and you're probably best off using something like zod to parse unknown objects.
Oh yeah, absolutely! I just wanted to show how to narrow from unknown to something more concrete. But I’d probably only use this approach for primitives.
@@andrew-burgess You validated that what was assigned to it at runtime was a number let a :string | number = 42; if ( typeof a === 'number') { console.log(a) }
@@andrew-burgess This is what ChatGPT says: "The reason why TypeScript still shows val.foobar as unknown inside the if block is due to a limitation in the current version of TypeScript's control flow analysis. Although TypeScript is able to narrow down the type of val based on the if statement condition, it is not yet able to use this information to refine the type of val.foobar to number. Instead, TypeScript conservatively treats val.foobar as unknown to ensure that the code is type-safe." So there you go, one day we'll get there. 😂 Btw, I also checked why Typescript allows us to assign 5 to val.foobar if val.foobar is considered unknown. ChatGPT said that Typescript is performing implicit type assertion in this case.
So you have me who is passionate about both this content creator and the language *TypeScript* watching a video about something that became somehow really trivial (It was not at the beginning do not worry if you are new to TypeScript and trying to understand *any* can *never* be trivial while it is *unknown* )...
The record example might be misleading. In the record example the reason for Record is following: You just verified that foobar is currently a number, but there is no definition that foobar _must_ be a number. So within your if, you can do number operations like "toFixed", but nobody is prohibiting you to write a string or anything else on it (no-type-declaration).
To solve this you'd need to create another object Object-B with clear type-definitions and pass the values to it. This way you define that Object-B must have foobar as number.
Great video. Lets say val is unknown and an object. How to get all components of the unknown object? So instead of checking if foobar in val, I want to get a list of all available components and then check the values of those components.
I just wish there was no production code that had the any type. I get it, but man are certain things hard to narrow down. And tryting to add strict mode to the whole code base is just going to make the Bussiness not happy for the tech debt it will incure.
any is the set of all set a cursed concept that is analogous to the nonexistence of both the type checker and set of all set then unknown is the set of all type... never the empty set...
you going over the parts of the language that i didn't know is a huge help, love your videos
That was the most clear and simple explanation of never, I've ever come across. You've really demystified it!
These types mixed with Set theory makes great sense. Thanks Andrew.
this video popped out on my recommendation but i watched the whole thing thanks
The exhaustive switch is amazing
Great video! Another use for the 'never' type is as the return type of functions that will always throw (e.g. exception helper functions). This lets the IDE detect any code after the function call as unreachable.
The simple and understandable explanation i have ever seen about typescript types
I will like every video you post because they’re all amazing.
Your explanation just gave me the 'ooOOOooohh!' moment. Liked and subscribed
Hands down the best explanation of these three keywords. Loved it! Understood it for the very first time. Thank you! Subscription already paying off!
amazingly clear explanation, subscribed!
Unknown is up there on the godtier list along with the generics
Thank you very much. very useful lesson. Thank you for sharing 🙏
I’m a hard man to please when it comes to developed TH-cam channels.
I’ve seen it and done it all.
I’ve got to say though that your content and the way it’s presented is vastly superior to a lot of channels that had exponential growth.
Thank you, man! SetTheory rules 💪
Nice explanation
Fantastic perspective
The colour grading of those video makes me so happy, the iconic face of Andrew even more and the quintessence of all that being about typescript is making me feel so privilege and lucky to exist in a univers where it is possible to witness any of this
Ha, you're too kind. Colour Grading === whatever comes out of my iPhone.
@@andrew-burgess you are filming this with your phone 📱 wow 🤩
You're killing it with these videos, Andrew! I think what many tech videos about languages miss is pragmatism and usage, after all anyone can read the docs and figure out syntax. However you've found a balance between theory and pragmatism.
Wonderful explanation
3:52 i would have mentioned that you probably wouldn't want to write a lot of this kind of manual object parsing code. it gets very messy and you're probably best off using something like zod to parse unknown objects.
Oh yeah, absolutely! I just wanted to show how to narrow from unknown to something more concrete. But I’d probably only use this approach for primitives.
Great explanation!
I assume that Record means that the type could also be Record ?
Hmm, maybe? Not sure why though, because I already validated that foobar is a number.
@@andrew-burgess You validated that what was assigned to it at runtime was a number
let a :string | number = 42;
if ( typeof a === 'number') {
console.log(a)
}
@@andrew-burgess This is what ChatGPT says:
"The reason why TypeScript still shows val.foobar as unknown inside the if block is due to a limitation in the current version of TypeScript's control flow analysis. Although TypeScript is able to narrow down the type of val based on the if statement condition, it is not yet able to use this information to refine the type of val.foobar to number. Instead, TypeScript conservatively treats val.foobar as unknown to ensure that the code is type-safe."
So there you go, one day we'll get there. 😂
Btw, I also checked why Typescript allows us to assign 5 to val.foobar if val.foobar is considered unknown. ChatGPT said that Typescript is performing implicit type assertion in this case.
At 4:30, that got fixed at version 5.5.
I bet you never thought you’d fall this deep into your tutorial watching journey.
So you have me who is passionate about both this content creator and the language *TypeScript* watching a video about something that became somehow really trivial (It was not at the beginning do not worry if you are new to TypeScript and trying to understand *any* can *never* be trivial while it is *unknown* )...
Thanks! Great video
5:20 ”That type of thing.”
I saw that you did there.
well defined
The record example might be misleading.
In the record example the reason for Record is following: You just verified that foobar is currently a number, but there is no definition that foobar _must_ be a number. So within your if, you can do number operations like "toFixed", but nobody is prohibiting you to write a string or anything else on it (no-type-declaration).
To solve this you'd need to create another object Object-B with clear type-definitions and pass the values to it. This way you define that Object-B must have foobar as number.
Thanks mate
Another use of "never" is the return type for functions that always throw an error.
Thanks Man....
02:29 How should we use the unknown type?
Great video. Lets say val is unknown and an object. How to get all components of the unknown object? So instead of checking if foobar in val, I want to get a list of all available components and then check the values of those components.
But I think you can check the type of a variable defined as any type.
I just wish there was no production code that had the any type. I get it, but man are certain things hard to narrow down. And tryting to add strict mode to the whole code base is just going to make the Bussiness not happy for the tech debt it will incure.
Now help me make use of Unknown type when i want to say that this unknown function argument is of type of my custom interface. How do i do that ?
any is the set of all set a cursed concept that is analogous to the nonexistence of both the type checker and set of all set then unknown is the set of all type... never the empty set...
I have to subscribe now, been coming across your clear and to the point clips for a while but somehow I didn't subscribe
Yeah it sends money.
I like never!
void vs undefined
Void: nothing to return. Undefined: create a variable and don't assign a value.
@@enzodossantos2546 It's confusing because in JavaScript when you return nothing you are actually returning undefined
type TODO = any;