Intermediate React, v4 TypeScript Discussion

[00:00:00]
>> Let's talk about my feelings in general with TypeScript. TypeScript you are trading off developer velocity and undoubtedly TypeScript makes you move a little bit slower for long term velocity and long term bugs. And the way the reason I say that is like people love to highlight that thing that I was just showing you where like it won't let you call to uppercase and a number.

[00:00:28] In general that's not my biggest problem. That's not generally my biggest issue with coding, a much bigger issue is that immediate feedback cycle of hey, you're doing this, this has this type has these things available. You can you can do these things, you can't do these things. And me doing that and then immediately seeing that inside of my code that right there is the value proposition of TypeScript.

[00:00:55] So any code that I might like rule of thumb in my brain is that anything that I intend to maintain less than, like two weeks or a month or something like that, I'll just write in JavaScript because I intend on going, I just wanna go fast, right? I don't wanna fight the TypeScript compiler for something that I'm not going to reap the benefit down the road.

[00:01:14] However, if I was gonna start any long term code base today, anything that I intended on maintaining longer than two weeks to a month, I'm gonna write in TypeScript, right. Because that maintainability and readability and documentation all that kinda thing makes me move faster in a long term perspective and means I have to maintain things less going forward.

[00:01:36] So I don't know is that makes sense? That's the trade off tight. There are some people that say like I use TypeScript for everything no matter what I'm not that person and there's other people say I will never use TypeScript which I think is a mistake. Okay, question.

[00:01:51]
>> How does TypeScript impacts the bundle size?
>> How does TypeScript impact the bundle size? So let me give you two sides to that answer. Simply adding TypeScript to a project as zero to the bundle. All the typescript compiler does is it just takes out the types, right?

[00:02:13] So if I go in here and and run this through the TypeScript compiler this code will look precisely the same. It'll just remove this bit, right? So that part won't make it into production. So from that perspective, it adds literally nothing. It doesn't add any runtime, it doesn't anything like that.

[00:02:33] TypeScript does not augment JavaScript in that capacity at all. Now, what will affect the bundle size is something like, yeah, let's look in Moodle, right? We had to do all this defensive coding in here Right, which we didn't have to do previous to TypeScript. That will I mean, technically increase your bundle size, right?

[00:02:56] Technically that does increase like the runtime cost just like a drop in an ocean amount, right? So I can confidently say that effectively it does nothing to your bundle size or your performance. But literally, yeah, you have to do some things like this but this is such a small amount of code that even the lowest end device is not gonna be any slower or any larger because because of that.

[00:03:23] So in other words, not a concern for performance that's we'll stick with that. Someone's gonna prove me wrong and whatever it's fine. What was the useBreedList return type? It's not in the GitHub repo.
>> Yeah. I'll go fix that. useBreedList return type down here, yeah. So before I had this returning without this, which basically is telling TypeScript this is a, it's not homogenous, right?

[00:04:00] It's not all the same type, so therefore anything that, any one index in here can either be a string list or it can be of type status, right? Cuz breed, this is a list of strings status of type status here, right? Which is not true, right, we actually have index zero is hard typed as a thing and index one is hard typed as a thing.

[00:04:23] So therefore we have to have this as string array so that this is always a string array and this is always a status. And the other thing is like, this can't have anything else in it right? So there's no index 2. You might be able to take it out and it might still work, I don't know, let's try, let's just run the type checker again.

[00:04:44] NPM run type check. No, see, it actually will air out there, so you actually do have to do that. I think you'll probably see having watched me done this and like I've done this a bunch of times now, but like, writing TypeScript code has a lot of guests and check, right?

[00:05:01] Did I upset the compiler? Did I satisfy the compiler? And I just do that cost? So that's what when I say fight the compiler, I really just mean that I'm doing a bunch of guessing checking. Cool I will say for however often I have to fight the compiler, I think in equal amounts on the other side of that, that I get something right away that I would not have gotten right away.

[00:05:30] Because the TypeScript compiler told me you're I expect that you're about to get this out of this right. So I like I call a method that I'm unfamiliar with and then tells me, this is what this object looks like. Previously, I either have to go read the documentation to what lodash dot something gives me right?

[00:05:51] Or I would have to run my code and console log out the object to see what I got back, right? Type script really helps you out in those kind of situations like, hey, here's your return type. Here's all the stuff you can expect to get back from that.

[00:06:04] Here's you can, I didn't show you this but let's see. What's a good example here. I mean here, like, request breathers if I just right command click on it, or I think it's Ctrl Click in Windows. It'll highlight here you can see request releases here. So it'll show me that it's there.

[00:06:29] Or if I do something like, fetch, it'll actually take me to the API definition here, which obviously this one's a little dense, right? This is actually for the browser but I can actually see the entire type here. Okay, fetch takes an input. It takes an a knit, which I don't know what that is, and it returns a promise with a response.

[00:06:51] And let's say I don't know what that is. I'm gonna right click on that. This is what a request and it is. It has a body, it has a cache credentials. This is something I would have had to go to MDN to figure out but now that I'm just command clicking on it in my VS code I can just pop around the various different API's here so I don't know what a request credentials is.

[00:07:12] Command click it can be include, omit or same origin neat, right? So this kind of like, really fast go to definition hopping in code is super useful. Or you can even do it in your code. So, where do I use breed? That's in search params. So if I go to search params.TSX and I have this like what is used breed list write?

[00:07:37] What idiot wrote that? This idiot did. But if I command click on it, it'll take me to my code here's like, okay, here's is useBreedList and then I can read the code that someone else wrote. Now, if you're writing like Java or like C++ like this is like yeah, I do this all day, right?

[00:07:56] But for people writing JavaScript, go to definition is a revelation for us or at least what like I missed it from when I used to write Java. TypeScript really allows your tools to like be augmented, which is, as a developer tools pm I'm very into that. Cool, any other questions about TypeScript?

[00:08:27] Yeah?
>> With this code and config and stuff work with Webpack or what would you have to do to get it to work and with Webpack?
>> Yeah, so the code and the config would all work with Webpack, cuz basically all of these tools are just bringing in the TypeScript compiler and running that.

[00:08:49] So Parcell does it that way, Webpack does it that way, yes, build all of them they're gonna do it that way. The question then becomes like, how do you set it up? And I think with Webpack there is just a TypeScript plugin that you include and it'll run the TypeScript compiler is one of the steps of Webpack building things.

[00:09:12] And then you'd have to have your Babel config ready to deal with types. That'd be it, Yeah it shouldn't be terribly difficult. This TypeScript is not hard to set up in most projects. It's hardest to get to play nice with ES lint to be honest but once it does then you can do a lot of really cool stuff.

[00:09:38]
>> What's your experience of how much TypeScript is used day to day at the companies you've worked in?
>> That's a good question. I would say most big companies that I know of now use some sort of typed JavaScript or if they're not currently they're all talking about it.

[00:09:59] And I think they all just recognize that when you have lots of engineers working on the same project it's just a really good tool to make sure that everything plays nice together. In theory it reduces the amount of runtime errors that you're gonna get but again I don't think that's the biggest benefit I think the biggest benefit is the productivity of the engineers work working on it.

[00:10:23] So yeah I would say most big companies are either on it or moving towards it. Atleast the ones that I work with. It's a good skill to know for sure and so I'll just plug Mike's course again like if you want to get in depth into TypeScript Mike does a good job of going through it.