Use noUncheckedIndexedAccess TypeScript Compiler Option and Improve Type-Safety

00:00 We've got an array including two strings and the type is obviously a string array. Let's create an element that exists. So that would be called element exists and let's make it array of index zero. So obviously array of index zero exists and this is the high string And TypeScript suggests us that the type is string, which in runtime, obviously, is going to be true. However, TypeScript is going to claim that every element by every index that we try to access is going to exist as well which could not be true.

00:39 So let's create an element doesn't exist which is going to be an array of let's say 100,000 elements and TypeScript will claim that this element also exists. So this is clearly unsafe. Even if we go crazy and create something that is totally stupid and that would be array of infinity which logically makes no sense since in computers which have, you know, limited memory etc. It's impossible that an array of an index which is infinity would exist. But still TypeScript doesn't care because if we take a look at what is the type behind the index access of an array that will basically say that this is T, the element of the array.

01:26 So TypeScript by default doesn't check it. So whenever you've got such code, Whenever you're trying to reach out to an element by a dynamic index, whatever, bear in mind that you should make an if statement to check whether the element exists or not. So let's make such a type guard. So in this case we would see that the element is a string but we will this is basically up to our discipline so let's try to enforce that on developers. So there is an opportunity to turn the no unchecked index access and using this option compiler flag we can change the semantics of how TypeScript interprets the index access.

02:18 Now, bear in mind that, let's take a look at the strict flags. Bear in mind that the no unchecked index access is not a part of the strict type checking options. It's not part of the family. So no unchecked needs to be turned on explicitly. So let's now refresh the page so that we can see how TypeScript interprets the types and how does it infers.

02:47 So what we can see is that definitely the element that could not exist is either string or undefined which is expected because the element could not exist and now our type guard does a perfect job here so that if we want to do whatever, to uppercase whatever that is and like behind the type guard it compiles correctly however without the type guard it will say hey object is possibly undefined which is of course what we want. But this flag, the no unchecked index access, is a double-edged sword. And that's because if we want to access the element which we are absolutely sure that it exists, It could be also something within a loop iteration like a for loop, for off loop, etc. And we might be absolutely sure that the element exists. This would still be either a string or undefined.

03:45 So when we turn this flag on, the issue is that whether you're unsure whether the element exists or not, this is what is beneficial, but also in such case we also need to go through the if statement. So pick up wisely whether it does make sense to turn on the no unchecked index access compiler option.