00:00 Let's talk about TypeScript's errors. TypeScript sometimes warns you about things which will definitely fail at runtime. Here const a equals null and we're calling a.toString. This will cause a JavaScript error. This will crash your entire app, okay? So it shouldn't let you do this. And the error it shows you is a is possibly null.

00:19 So the errors here are slightly different from, it's not telling you exactly what's wrong. It's kind of giving you an error in the right place and making you think, oh, I probably can't call toString on null. Right, that makes sense. So TypeScript sort of gives you the warnings that you need,

00:37 but sometimes it talks in a little bit of an obtuse way and expects you to pick up the rest. Not everything though that it warns you about is gonna fail at runtime. This object here, it's just an empty object we're declaring with obj. And then we're saying obj.foo equals hello. Now obj.foo equals hello, that's not gonna cause an error at runtime.

00:56 This is perfectly fine behavior. We're gonna end up with like an object that sort of looks like const obj2 equals foo hello. And this is perfectly fine. But if you think about it, would you prefer it if TypeScript didn't error this way or that it did error this way? If it didn't error this way,

01:17 then it would basically be saying, okay, you can just assign anything you want to any object at any time. And probably over the course of an entire application, this would result in probably quite a few bugs. So if you think about it, TypeScript is just really a rule set that is a bunch of different compromises.

01:35 Sure, it's kind of erroring here in a situation that it wouldn't fail at runtime, but it's only doing that because it thinks on the whole, this will result in you doing some safer coding. So of course, the best thing that you can do here is you can save, you can actually give it a type of foo string. And this will make the error go away. But of course, we'll look at this situation

01:54 further down the line. Now, it will try to warn you as close to the source of the problem as possible. So here we have a type of myUser. And we're saying const user is myUser. MyUser has a property of name string. And we have given like a type here or passed a property, which is incorrect.

02:14 It should be name, but in fact, it's NME. And so it's saying type NME is not assignable to type myUser. Object literal may only specify known properties, but NME does not exist on type myUser. Did you mean to write name? This is on the other side of the spectrum where TypeScript is giving us a perfect error

02:34 for this exact situation, and even a suggestion on what we should write. And so of course, the thing to do here is just to autocomplete your way there and say name, fantastic. But sometimes like, and you can see that the error is like exactly where it needs to be, which is beautiful. But sometimes TypeScript won't give you an error in the exact spot that you need to.

02:53 For instance, here, we are creating a function type. And this function is a function that returns a string. And here, instead of erroring on the one, two, three, which is the actual error, because we're returning a number, not a string, it's giving us an error on the actual function itself. This is because functions, when you compare them together,

03:12 you have to compare the whole thing, which we will look at later. But it means that you get the error further away, than what you expect. Whereas we could restructure this slightly and instead give a return type to this function. And we could just say string here. And now it will give the error closer in. So TypeScript does its best. It really does try to make sure

03:32 that the red line is exactly where it needs to be. But sometimes because of things that you're doing, it can't quite do that. So this is a good introduction for TypeScript errors.