Intermediate React, v2 TypeScript Review and Q&A

Transcript from the "TypeScript Review and Q&A" Lesson

[00:00:00]
>> Brian Holt: And now when we look at results, results was fine, SearchParams is now happy, you can see that one's outlined in green. And now, this is the most difficult one of them. So we're gonna say App.js, we're gonna rename it to tsx here. And never mind, I'm just kidding.

[00:00:20] It's, it just works. So we didn't have to change anything with this one. Because we typed everything else, we got to this one, everything was fine. But I saw all your faces. It was like shit, more of this. Okay, so that was the entire thing. The one last thing that we have to do here is we have to go to index.html and we have to change this from app.js to app.tsx, right, cuz otherwise it wouldn't be pointing at the right file.

[00:00:50] And now hopefully if you say npm run dev.
>> Brian Holt: Everything should just work out of the box. So you can see it's all coming from TypeScript.
>> Brian Holt: Built in ten seconds, we'll go look at the project. And notice that it still builds and everything still works. Question?
>> Speaker 2: So, on the interfaces, I've seen in some of the projects that I'm working on, they use the interfaces as a separate file that they import.

[00:01:21] And I noticed you put them right into the file. Is there a preference, there's having it in as a separate interface file, or just putting it in the component that you're using it in?
>> Brian Holt: That's a good question. I think it's gonna vary a lot team by team.

[00:01:35] For, specifically, for props and state, you should definitely put them in the same file. And I don't feel like that's super controversial to say, because it's like documentation of that component. It wouldn't make sense to separate it. But for example, we used our animal and photo type everywhere in this application.

[00:01:51] Now, if that wasn't defined in a library, I would have a separate interface file that would define those ones. So I guess that's kind of the line I would choose. If it's used in one file, just define it in the file. If it's used in a bunch of files, maybe split it out into a different type definition.

[00:02:05]
>> Speaker 2: Cuz the way I've seen it is they'll have a directory for that component and in that directory component, you have the component, and then the prop, the iprop and the istate interfaces. And they're just used there.
>> Brian Holt: Yeah, and that seems sane, I wouldn't be upset to see that in a project that I worked in.

[00:02:20] I'm a little bit lazier that I like things to be in one file, as much as possible. But that's a perfectly valid choice to make. I don't think there's a, you must do it this way, kind of thing about that. Does that answer your question?
>> Speaker 2: Yeah, I just was wondering if there's a reason, cuz I prefer it all in one, cuz otherwise you kind of open up another file, you're looking for it, and as opposed to having it just right all there, you can see.

[00:02:44]
>> Brian Holt: Yeah, some people just adhere to the standards that they feel like they should, right? Cuz a lot of people will just separate, they don't think that definitions and code belong in the same files. And I can't see why not, right? But again if you're sharing that across a lot of repos, or a lot of files, then it does make sense.

[00:03:02] Cuz you're gonna be importing it from multiple different places, right? So that's my opinion, but it's not the opinion. It's just a really good opinion. Cool, good question. One more thing I want to show you before we totally wrap this up. So right now, we've just been doing everything using our editor.

[00:03:24] But I want you to go into your package.json, not package-lock, package.json. And we're going to put one more thing in here called typecheck, typecheck. And we're just gonna say tsc --noEmit, like that. And what this is gonna do, this is something you could run in your CI or you could run it locally before you commit or something like that.

[00:03:48] And so now I can say my project npm run typecheck. So that maybe your colleagues are using vim or something like that and they're not using Visual Studio Code. They could run this before they commit to just to make sure that everything compiles correctly. And so nothing happened here, so it means everything passed, right?

[00:04:08] But if there were problems here they would show up.
>> Brian Holt: Okay, any questions about TypeScript?
>> Brian Holt: Do you want to do it again?
>> Brian Holt: I'm a big TypeScript fan. I think legally I'm obligated to be. But also I already liked it before I joined LinkedIn or before I joined Microsoft.

[00:04:33] My kind of ethos in here is that I'm going to, if I'm just gonna make a really small project, I'm gonna just write it in JavaScript and get it done and just move on. But if I write any sort of project that I intend on maintaining longer than like a week, I'm gonna write it in TypeScript.

[00:04:47] Because I think ultimately you're gonna get longer term gains. But the tradeoff what you're making is you're trading off short-term productivity for long-term productivity, right? This takes longer to write. Undoubtedly, it takes longer to fight TypeScript. You saw me fight the compiler several times, right, and this was pretty tame, right?

[00:05:08] There can be some Route holes so that you just go super far down, that feel pointless. But in the end, it forces you to think through your code, because you have to think, okay, this goes from a string here, becomes a number here, goes into an object here.

[00:05:21] Like, it forces you to think through these things and you end up with better code. And you end up with additional assurances that your code's not gonna crash. So if anyone starts yelling at you, every project should use TypeScript, like, not even the TypeScript team thinks that, right?

[00:05:36] So not everything needs to use TypeScript. It has its place. But in my opinion, every big project should really consider adopting it.