Transcript from the "Rationale" Lesson
>> Mike North: So why would we wanna add types? Why would someone bother to make this project? First, it gives us the opportunity to take assumptions and constraints we have as authors when we write a piece of code. It gives us an opportunity to make those a part of our code.
[00:00:33] But you'd be relying on people reading your source code and finding that. You could assert that it's a string like within the function, throwing error if the type of this value is not a string, but that starts to add up. It starts to get towards something we would call defensive programming.
[00:00:55] Which is where you basically don't trust any of your inputs and it introduces a lot of overhead and complexity, both performance overhead and cognitive overhead, right? You hire a new person to your team and they're gonna have to weave through the stuff and figure out where are the assertions and what's this function actually doing after it's satisfied that the data is correct.
[00:01:18] It makes things a little difficult to maintain. So this types assist us in taking all of our developer intent and encoding it into the code we write. Types help us catch common mistakes, like a spelling error. I make spelling errors a few times a day, at least leading up to my second or third cup of coffee, spelling errors are very common.
[00:01:46] So because there's a validation that you're only accessing the properties that you should be accessing and that you're naming your arguments correctly. You're less likely to make those with types because you've defined what should be accessed, and everything else you should not be trying to touch. An incomplete refactors and other good example.
[00:02:33] You'll see throughout our work today that we're moving a lot of errors we would find at run time up to compile time. So we're getting earlier feedback and we're getting feedback as a result of static analysis. Which is an analysis that just looks at your source code and comes to conclusions.
[00:02:53] As opposed to runtime analysis which requires you to actually go through and execute every path of your code. So you could catch some of the stuff with tests, absolutely. But while you're writing your code and maybe you haven't written your test yet, or maybe your test are incomplete, is anyone here worked on a project that has an imperfect test suite?
[00:03:17] I have, all hands should go up right now. All of your test suits are probably imperfect. So, this means you are not depending on tests to catch this type of error. You certainly can make other types of errors. And then finally right away, you're gonna see that TypeScript is the foundation of a great developer experience.