Transcript from the "Wrapping Up" Lesson
[00:00:00]
>> So as part of testing, there was that question someone asked in the class. About whether it's possible to create an extension of a declaration file and name it something else so it doesn't interfere with other foxy declaration file? Now, there's a little bit of a flood premise to this question.
[00:00:22] And I just wanna emphasize again, that type checking is a global operation. So there's no sense of like, in some of these files, I use this one declaration file, and these other files I use another. It's one thing, it's a holistic process that happens to your entire App.
[00:00:39] So if you want an override to happen, that override applies everywhere. What you can do is import types from one place and export them as something different, but that is not the same thing as sort of like patching React. If you patch React, that patch happens everywhere, right, so think of it almost like you're programming with globals.
[00:01:04] There's one React and its types are represented once many places may refer to them. But any little adjustments that you make to those, they happen for your whole App. The question is, why is it that we have to use these tools and not Juxt, Juxt, or the standard tools we're used to when writing our tests?
[00:01:25] So there are many ways I could answer this, but I really only need one, I think there's one compelling answer I can give that is enough. And that is the following, You can have bugs in your types that allow too many things to happen, bugs where your type information becomes too wide.
[00:01:50] Let me introduce a bug. Does anyone wanna argue that this is not a bug, this is not a problem that I just created? I took this interface and I made it in any, what will this break? Nothing, it won't break anything and that's a problem. It should break lots of things, it's too general, it allows things that it shouldn't allow.
[00:02:28] Juxt can't catch this, Juxt we'll be perfectly happy to let you pass in team as an argument to return a team. And there will be any, any, any, any, any suggests can't catch this. It's really all about those negative test cases, which are really hard to write and something like, you're just types.
[00:02:49] Where you wanna make sure certain things are not allowed, certain things should raise errors, certain things should be impossible. It is as important to maintain those conditions, as it is to maintain things that should work, should work, and things that shouldn't work must not be allowed to work.
[00:03:12] And this is a kind of error that your regular test suite is just not gonna be able to catch. Whereas over here, I'll tell you, this one will catch it, right? So even if I fix this file, I introduced the problem here deliberately, right? So one should be a Team and one shouldn't, but the bug I just introduced will have both of these to be regarded as an ITeam.
[00:03:37] Uhuh, what happened here? Expect non assignable, no, I would expect this to fail, There it goes. I must not have saved something, so it's telling me a no is assignable to an any. And I was supposed to check and make sure this was not allowed to happen and it could happen, that's a problem.
[00:04:10] I can't really write the same kind of test in Juxt, not in a way that produces good assertion errors like this. So that's the answer, you need this mostly from negative test cases. And this is so often overlooked in TypeScript code and his kinda bug happens all the time.
[00:04:28] It'll just be like a patched version of some definitely typed package, that'll introduce something like this. And you'll just wonder, it just takes, I've spent weeks tracking down bugs, this would make easy to fix. And, instead, I was just this big chase to try and figure out what the heck is going on.
[00:04:45] And, I ended up having to write these tests, anyway, because that's how you track this kind of thing down. You start saying, okay, well, this should be possible and this should be impossible. And you just keep adding these cases as you try to find like, okay. So here's the thing that shouldn't be allowed to happen and it's happening, now I know where to look.
[00:05:02] But it's just really, really tricky to find these problems, every failure of this nature will be mysterious and time consuming without a good test suite. So, thanks so much for spending the day with me talking about professional TypeScript. I hope that you feel that you're not only able to use the programming language now.
[00:05:24] You're familiar with some of the best in class tools that when put together, make life easier. I hope you automate things like your various types of tests. And I hope that this will be the beginning of your exploration deeper into this ecosystem. As this language continues to gain in popularity and become one of the most exciting parts of the web development ecosystem.