Here are a couple links that have helped me understand these types: ivov.dev/notes... www.zhenghao.i... blog.thoughtsp... My Blog: shaky.sh My Coding Setup: shaky.sh/tools/
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.
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.
@@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.
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.
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.
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...
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! 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.
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* )...
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.
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.
Nice explanation
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.
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.
Great explanation!
Thanks mate
02:29 How should we use the unknown type?
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 ?
you going over the parts of the language that i didn't know is a huge help, love your videos
At 4:30, that got fixed at version 5.5.
That was the most clear and simple explanation of never, I've ever come across. You've really demystified it!
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.
Thank you very much. very useful lesson. Thank you for sharing 🙏
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.
I have to subscribe now, been coming across your clear and to the point clips for a while but somehow I didn't subscribe
Unknown is up there on the godtier list along with the generics
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...
These types mixed with Set theory makes great sense. Thanks Andrew.
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.
this video popped out on my recommendation but i watched the whole thing thanks
Yeah it sends money.
I will like every video you post because they’re all amazing.
I like never!
type TODO = any;
well defined
Thanks Man....
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.
Your explanation just gave me the 'ooOOOooohh!' moment. Liked and subscribed
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* )...
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.
I bet you never thought you’d fall this deep into your tutorial watching journey.
But I think you can check the type of a variable defined as any type.
amazingly clear explanation, subscribed!
5:20 ”That type of thing.”
I saw that you did there.
Thank you, man! SetTheory rules 💪
The simple and understandable explanation i have ever seen about typescript types
The exhaustive switch is amazing
Thanks! Great video
Fantastic perspective
Wonderful explanation
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 🤩
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
Hands down the best explanation of these three keywords. Loved it! Understood it for the very first time. Thank you! Subscription already paying off!