Matt Pocock answers your TypeScript questions
===

[00:00:00] Welcome back to PodRocket, a web development podcast from LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it for free at logrocket. com. I'm Noel, host for PodRocket, and today we're answering questions about TypeScript.

Uh, Last month we had you guys send in what you were struggling with When it came to TypeScript, , so we're taking the time today to talk to the TypeScript expert, Matthew Pocock, to answer your questions. Welcome back to the podcast.

Matt, how's it going?

Not bad at all. Thank you for the Matthew. That's very brave of you. Most people just go Matt.

Oh no. Yeah.

I'm terrified of like people's full names because I once, like one of my friends who was a developer, his name was Ben and I said, I called him Benjamin one day and he said, no, my name is actually Benedict.

Benedict. Oh my days. So I'm not a Matilda. I'm not a Mateus. I am a Matthew. So well

nice, nice. Yeah. , I'm with you. Let's talk about TypeScript though. , I'm just going to start burning through questions. These are like varying degrees of I don't know, technical depth and stuff.

We've got a little bit of everything in here, so [00:01:00] hopefully people can learn regardless of what your kind of current skill level is or one's current skill level is. So I guess, yeah, starting from the top one person wrote in that they're still not sure that TypeScript is the like go to when it comes to selecting between it or just JavaScript for a given project.

Especially when we take into account that TypeScript must be compiled to a clean JavaScript anyway. What would you say to that?

I think it's weird because, so I think a lot of my job, so my job is basically as like a TypeScript educator, right? So I've been, just like talking about TypeScript for, I think I went full time about a year ago, let's say, and. I really haven't had to do that much really selling of TypeScript, like a lot of what I've done really is just focusing on just trying to teach people how it works because TypeScript just sells itself really.

Like , I guess the pain point of this user or the listener is trying to say is sure, you've got to compile your types. You need like a compilation step [00:02:00] because the ts files can't just be put into the browser. And really what your. Weighing that against is how good do you want your IDE to be?

Do you want your IDE to hold your hand and be with you the entire time and actually give you autocomplete, give you errors in your IDE, or do you want just to roll it on your own, and a lot of people can do that, they can just work in JavaScript and just plow through stuff and, but especially if you're working in a team, I think TypeScript just has the edge.

And like that conversation, it feels especially with everyone I talk to, really, it feels like either teams are choosing not to use TypeScript because they've had a look at it and they think, actually, no, we're going to be better just using JavaScript ourselves, or they're going, okay, yeah, let's use TypeScript, but TypeScript is always in the conversation.

There's no real alternative, it's either TypeScript or not. And. I think in that case yeah, if you're worried about the compilation step, if you just want to see your code in the browser, then maybe you shouldn't use TypeScript, but if you feel like TypeScript benefits are worth something to you, then [00:03:00] it's weird.

A lot of people I know use TypeScript and then they don't go back. I don't know. Is that your experience? Would you go back to JavaScript now? I don't know if you're even a TypeScript native developer, you like JavaScript or you like TypeScript.

No, I like TypeScript for sure. Yeah, I would. Yeah, I think I'm in the camp where it seems. There's be very little benefit to switching back like it's easy enough for me to just pull the escape lever in TypeScript if I ever need to for some reason or it isn't an issue. I guess maybe I'm curious here with this compilation step being the thing that was asked about, have you ever encountered cases where there is an issue that would have been avoided?

Were the code just being written in JavaScript, like something happening in transpilation that would have not been an issue?

Yeah, this is a good question. So like it's never happened to me and that's a testament to TypeScript's kind of robustness really I tend to actually not use TypeScript to bundle stuff I tend to use something that's a bit faster like ES build or like SWC Or something that kind of can take the code and very quickly [00:04:00] using, rust or using Go or whatever it's written in, just like jam out some JavaScript code.

And I use TypeScript primarily as a type checker, but let's say you're talking about someone like Rich Harris and the Svelte team. So have you heard about this? Like they recently just took all of the code. That was the Svelte compiler and rewrote it in JavaScript. So they took it away from TypeScript.

You hear about this?

Yeah.

Yeah. So instead of TypeScript, what they used was JS doc and JS doc is basically like TypeScript annotations, but in JavaScript. So you just put them in JavaScript comments. And. A lot of people just say it's horrible. Why would you do that? Like you've got this beautiful TypeScript native syntax and then you're just using this kind of comment stuff instead, but actually you can still get a pretty good experience using that.

And it also means that for them, they didn't have to. Like the thing that's important for them is they needed to like debug all the JavaScript code that was like running through and they didn't want to have to do that via like first take it in TypeScript, then do a [00:05:00] source map into the JavaScript where you like link all the JavaScript line by line back to the TypeScript code and have all of that overhead.

They just wanted, okay, debug the JavaScript directly and you're walking through and you can see everything. Sometimes if debugging really is an issue for you, and mostly it's not going to be if you're working in application code instead of. Compiler code, then you might want to consider just using JavaScript and JSDoc.

But I think a lot of that kind of Rich Harris Svelte conversation has just been blown up where people are saying, Rich Harris hates TypeScript. And he keeps getting tagged on like all these threads of people say, Rich, why do you hate TypeScript so much, man? But actually he's I love TypeScript. I just didn't want to use it for this specific case.

Yeah. Yeah. Do you find yourself getting pulled into those? I don't know. Dialogues on social media. I guess maybe we should frame this a little bit. Can you give us a brief. Listen, there's a brief on like who you are, like the, two minute version and your context here on why you're a good person to be talking about [00:06:00] TypeScript.

. Good point. So about a couple of years ago, I was working on a library called X state. I think I actually came on here talking about it as

Yeah, you did.

And I worked at a company called stately and we were trying to make the TypeScript experience of this library a lot better because it was pretty, pretty rubbish.

And. We did. And in the process, I learned a lot about TypeScript and started posting on social media about it. Went from, I don't know, 4, 000 Twitter followers to I think 98, 000 or something crazy. So it's it's gone nuts in the last year. And I worked at Vercel for a little bit doing, dev rel for turbo repo.

And now I'm just full time doing independent stuff. I've got a course on TypeScript at turtletypescript. com and that's me basically. So I'm now weirdly elected, like the TypeScript person who gets, I'm the TypeScript talking head. I don't have any connection with the team or anything like that.

I'm not an official representative of TypeScript, but I don't know. It's.

finger on the pulse though. Yeah, so like how do you find most of these dialogues going? Like this, I don't know this straw man that people were standing up with Rich. Do you feel obligated, [00:07:00] compelled at least to weigh in on this kind of thing? Or are you watching from the sidelines with your popcorn in hand?

Yeah, it's also, the thing about TypeScript is it's so staple, it's been around for 10 years, it's just growing and growing in popularity absolutely dominating the market in terms of people using it. And so it's very hard to find any drama about it, and so when someone actually says.

We're not using TypeScript for this specific use case. Everyone goes nuts and says, no more TypeScript for library development, no more this, no more that, but it's just feels like one of those passing phases, really. Just things do at the moment in terms of react and the app directory and all that kind of rubbish it's just stuff that passes by really.

So I just try to keep focused on instructing people and teaching people how it works. And that sort of stuff is just, timeless good content, hopefully.

Yeah, for sure. I guess one of the other kind of questions we had along this vein is the inverse is someone asking are there unchallengeable and undeniable factors that make TypeScript better and faster than pure JavaScript? It sounds like this person's like looking for ways that they [00:08:00] can help justify like moving a code base or something.

Do you usually have something you give those people?

Yeah, I'd say, so I saw an interview with Anders Helsberg, who is the mastermind behind C Sharp and TypeScript. Very clever dude working at Microsoft. And he said that 10 years ago when they were first thinking about TypeScript, the tooling for JavaScript was awful. Just crap, right?

So you didn't have, you couldn't do like file refactors, like you couldn't refactor things across a project. If you try to change some JavaScript code, it was just awful. And I remember this was actually before I became a developer, but I was still messing around with stuff and, notepad plus.

And I was just terrified of changing things on mass, awful situation and TypeScript solves that problem, right? It makes your IDE better and it makes your development experience just more comfortable. And the main thing it does, I think the thing that keeps people coming back is that if you do one of those big four hour, like refactors in JavaScript, [00:09:00] that will just take you five minutes in TypeScript.

It's that's the huge differential is that it just lets you refactor code a lot easier. And it means that you've just got so many more options in your IDE. You can. Rename a symbol across multiple files. You can jump to find a definition to go to different places. And it just turns you into a faster developer because your ID is way better.

Yeah that's what I've, how I always answer that as well. I found it just makes me so much less. I'm timid to do refactors. I just like before I would, I feel when I was writing, in a non type language at large, in general, I would just be like, okay, I want to change this function, signature.

Cause I've got to change the whole paradigm here. I need to move context in or out of a function. And before it was like, okay, I've got to make sure I look at all the places where this is being called. Where is the, where is that argument coming from? Chase trace it all the way up. Now I can just start with that function and be like, this should be this here.

And then I'll get the errors bubbling all the way up and I can just naturally follow it through the call stack. And every, I'm not worried that when I hit run I'm gonna have missed one case. It's no. The [00:10:00] compiler's got my back. 

Exactly. And it's, for me, it's all about time to error. If you think about like your coding, it's like a performance metric. Time to error is really important because if you make a change and you're having to tab over to the browser to even, let's say, you're working on a multi step form, let's say, and this multi step form, you've got to go to the third page of that form in order to actually see the error.

Every time you make a code change, you're going to have to go in through bam, go in and type all this stuff in, and you're going to try and see your error there. And it turns out it might just been a fricking typo or something that's like messing you up. Whereas. TypeScript, it's going to be really sharp in terms of time to error, because it's just going to be right there on the page, jumping out at you.

And usually it's right, unless you're doing really dynamic stuff and where you need TypeScript to shut up for a bit and it lets you shut it up, then usually it's going to be right about stuff. And that time to error metric just makes you so much faster.

Yeah. Okay, cool. That's a good segue. We had another listener wondering about just like the dev environment set up for linting [00:11:00] testing debugging. What do you recommend to people to ensure that they've got that feedback loop quick? So they can fully reap that benefit.

Yeah, I think, the main thing is, I think TypeScript works with lots of different IDEs, but the main one is famous for working with is VS code and VS code has TypeScript support out of the box. Like you don't even need to install TypeScript in order to get that support. It's actually just got a version of TypeScript kind of messing about inside it.

So that one, is the first one that comes to mind, you can also if you want to be really sure that your TypeScript setup is running okay, so there's like dev environment and there's CI stuff. If you think about, there's a CLI called TSC, which is the TypeScript CLI. And if you think about TypeScript as like a.

It's like a teacher just hanging over your shoulder and marking your code and saying, you got this wrong, you got this wrong, you got this wrong. Then you can use the TypeScript CLI to basically say, it's like handing in an essay to your teacher. And [00:12:00] that's like saying, did I, across this entire project.

Did I get anything wrong and typescripts will then say, you've got this one got this wrong And this is amazing for those big refactors where you're changing tens of different files and stuff And so there's a version of that where you can say type tsc watch And whenever i'm doing anything major on a project, I will generally have that running So what it does is it just basically says okay whenever I change a file check the entire project And tell me if i've got anything wrong and that means then that when I go to my browser, I know that Everything's good on that end.

And it's probably just some logical error that might cause a bug or something.

Yeah. Is that TSC watch? Like I found the output of when I call watch manually to almost be identical to what if I just set up a project naively in VS code and let it do its thing the errors list seems identical most of the time. VS code may be a little bit slower. Maybe there's some optimizations there.

Do you know anything about the internals? What it's running across your code base?

Yeah. So what VS code is running is [00:13:00] it's running, like the way it works is there's like a TS server that runs in the background. And I think what it does is it doesn't run TypeScript on the entire project. Cause that would be quite slow, but what it does on the files that you're looking at, it.

Goes into those files and then looks at the graph from those files. So it looks at the dependencies, looks at the dependencies of those, and it constructs a partial graph of what your project is based on what you're looking at. So that means that you're not going to get a complete overview of your project based on that, but you are going to get fairly solid, very solid information of the stuff that you're working on.

So what you might've done is you might've changed something downstream and TypeScript hasn't actually like filtered or rather. The TS server on VS Code hasn't filtered through the entire project and picked up all of the leaves of that change. So that's why there's a different output.

Yeah. Yeah. Is there anything that you've found? I guess in my projects, I usually just have that TSC step, like in my pre build. So like on my dev [00:14:00] environment, I'm not worrying about it. And then I just make sure that like, Hey, when I'm doing a full build or want to run the production version, I hit it.

Do you find that you're like TSC watch output is leading you to go fix bugs more proactively, or do you think like it's a reasonable workflow to save that for. Like the pre commit, like right before you're signing off.

Yeah, if you're, it's like a choice, right? It's do you do it on your local dev environment or do you wait for your CI to yell at you and do it there? Both are valid, both are valid. One you, I, if I'm doing like a big change that I know is going to be affecting a lot of files and I'm worried about what my CI is going to say, then I'll do it locally.

I'll always have it on CI because on CI, that's like TypeScript's main benefit as well is that you just get this green tick mark. If you just got everything right, it's fabulous. But if I know that I might get on the wrong side of that, then I'll have it running locally, but. Yeah, it's, I think that answers your question.

I ran out of steam there.

No. That was good. So yeah, let's I'm let's like try to move through the stack, like from dev to [00:15:00] test to deployment. So there's a couple more kind of in the dev sphere I want to cover here before we do that. There was one, let me see if I can find this question. Yeah, they're asking about design patterns and like kind of TypeScript's relationship.

They're asking what are the specific use cases for different design patterns to use with TypeScript? What are some steps that can make working with those design patterns easier? Have you found there's any kind of anything unique to TypeScript in particular that makes certain patterns easier to deploy and utilize versus just vanilla

Yeah, for sure. So TypeScript does a lot of it's all about the shapes of things. So every time you declare like an interface or a type, then you're declaring a shape that something has to correspond to. And what TypeScript is really good at is making sure that every line by line, the shape of something is as you think it should be.

This means. Quite naturally, it's better with immutable data structures instead of mutable ones. Because if you're mutating something line by line, then you're changing it as it [00:16:00] goes and you're not really able to tell TypeScript what that new thing is. That means it's, let's say you're mutating an object, for example, and you're saying, okay, I want to take this array of things, stick these all in an object.

It's going to be quite hard for you to dynamically type that really, so you're going to need some type signatures on that. And, but that's fine. TypeScript also, it's really like the more complex your JavaScript is, the more complex your TypeScript is going to be. Because TypeScript just describes JavaScript.

That's all it does. It doesn't add any, anything extra, really. It just does some stuff on top to make sure that your JavaScript is doing what it's supposed to be doing. Really, it can do everything that JavaScript does. There are no patterns that you can do in JavaScript that TypeScript can't do. It's all about what's more idiomatic to TypeScript.

What's easier to do. What requires fewer annotations. And in general, what that means is... Programming in a more I don't know about functional style, but TypeScript really [00:17:00] just loves functions. That's what it loves. And if you're designing like an API or something, and you're finding that you're, you need people to like, mutate stuff or do lots of sort of class inheritance.

It's good with class inheritance as well. Good with OOP, but functions is really where it shines. And that's where you can really use the more powerful TypeScript features to your advantage. So I don't know about specific patterns and stuff, but use more immutability instead of mutation.

And TypeScript is really as flexible and wide as you want it to be.

Yeah, I think I guess I agree. That's what I found as well. I found I'm not like a functional diehard, like a lot of devs are, but I do think that I go out of my way heavily to write code that is like very functional. I'm even hesitant to use a case statement or something. A lot of the time we're like, I'll break something out into a function, even if I'm adding additional lines, just because I know I don't have any extemporaneous state at all.

There's zero mutations here. If I can just go into a function and I think that TypeScript. Tends to point me that way. It wasn't like a conscious [00:18:00] thing when I started using it, but it it just feels the inference is smarter. Like it makes me even more hesitant to like mutate at all. It's no, everything needs to be static.

Like I just know what's going on.

Definitely. And every function you feel really good about, because, you've got you understand what all the arguments are strongly typed. And so you can capture stuff in that function and it just makes you feel warm and fuzzy. Really? There's not that much kind of global stuff that you can interact with if you don't need it.

And and also I'd say that. It's also pretty hard to type this, for instance, in TypeScript, and it's certainly possible, but it's just not very idiomatic, and so you end up not using that much in terms of classes, in terms of this on objects and this in functions and stuff, just because it's a, it's just easier just to type a function and have a function and just do it in the normal sort of way.

Quasi functional way.

Yeah. And there's probably something there. Again, I've never been like a huge, a person that like is super reliant on the object oriented paradigm. So I'm probably [00:19:00] not very well equipped to speak to that either. But I guess if you encounter people that have, that were like, have operated in that way for a very long time, they're very familiar with it.

It's how they expect code bases to look when they're in them and they rub up against this, Suggestion the TypeScript is making, or it's preference towards having code that works this way, just in ease of the dev experience. And that kind of be a point of I don't know, just friction for them at all.

I think it's easy to look at TypeScript from the surface and say, Oh, I see TypeScript has it has native support for enums. So it has native support for interfaces and classes. Oh, that's interesting. Oh, the guy who made TypeScript, he's, he made C sharp, didn't he? So I see. So it's like a C sharp in JavaScript, but it's.

And that might, it's often the opposite. Actually. Often people say, like this is way too object oriented for me. This was an early criticism of TypeScript. It was like, no way, man. It's just C sharp and JavaScript. And I've had to field that opinion as well, but it's not, it's just not like it's, [00:20:00] if anything, like TypeScript, I think probably interfaces might not be added, no interfaces probably will be added for various reasons, but enums wouldn't be added, I think classes, if they didn't exist already in JavaScript.

Wouldn't have been added in TypeScript. So yeah, I dunno, that criticism sort of rings a bit hollow to me, but it's gotten a lot more flexible and I think TypeScript's job really these days is just to describe JavaScript and just to what JavaScript does, and it's doing a great job of that at the moment.

Yeah. So this is another decent segue here. We had someone ask about building generic components in TypeScript. I'm not completely sure if they're asking about typeScript generics or front end components in the React world that are good at handling like different shapes or kinds of data and rendering them.

But I think the second one is probably what they intended. So is that kind of what, yeah, 

I think I've got a handle on what they're talking about. I'm actually working on a React and TypeScript course at the moment. So like I've [00:21:00] literally finished recording like the generics section of that, like a few days ago. So my head is very much in that

Nice. Perfect. 

So it's funny because I actually asked on Twitter the other day what use cases do you have for generic components?

And there were only like three that came back. The main one is tables, right? So tables, let's say, let's just say you've got. A table component that takes two props, takes in a data, which is just like an array of stuff, and takes in a render row function. That render row function is going to be called for every row of that data, and it's going to render each row.

So it means you can basically have a table beautifully formatted and everything, have all of your styles encapsulated in one component, but you can make it dynamic to different types of data, which is super powerful. And it's a pattern that I think everyone should have in their CRUD applications.

If you're showing tables or showing lists of anything, lists of cards, really what that means is then you can feed in different types of data, like users or posts or comments, and then you can render that [00:22:00] differently. But the issue is that. You really want the renderRow function, the row that's the argument passed to that, to be inferred from the data that you're passing in. So you've got this bit of magic that needs to happen. And in a normal function, you would do that just by having a type argument. And in TypeScript, You can infer type arguments from runtime arguments. So what you need is on that table component. You basically just say, okay, I've got this type of T row or whatever, and infer that from the data and then put it inside the render row function and boom, you've got a generic component.

So like tables select boxes, and also something like the as prop as well. Polymorphic components is also pretty major for this kind of thing. But I think that's the mental model you need. In first something from one prop and pass it to another.

Yeah, that's yeah, I guess is there terms that people should be, again, like the listener that asked this question, is there something that they should be like Googling, looking up particularly to see a good example of this pattern?[00:23:00] 

Yeah. Generic components. That's what they're called. Generic components is and I guess type parameters, type arguments. They're called generics in the TypeScript docs as well.

Yeah, I found that they work pretty well. Yeah, I think that they're, it was a little bit of a road bump for me early on, but it's like once, once I don't know once it's oh, yeah, they're just generic. So just I don't need to make this isn't special because I'm rendering it.

It's still just a generic, like any other function that I want to be able to have a generic

If anything is a bit easier as well, because like in a normal function, you might have a generic that you take in and then put into the return type or something or transform into the return type, but components, they just all return the same thing. They all return JSX, or null. And so really you're just talking about literally a generic inside the props and that's it.

And yeah, there's lots of different things you can do with, React and TypeScript and props. It's a big wide world on that.

Yeah. So on this, Props kind of function arguments, thread the, someone asked, and this is not really my, this is a bit probably beyond my TypeScript grasp, but they're asking the type argument feature and how it's going [00:24:00] to solve the partial Interference is the word that they use.

I don't know if that's a word in type arguments, what are they talking about?

Yeah. I saw this question and it's interesting. So what they're talking about is partial inference, right? Now in TypeScript, what you can do is you can declare a function and let's say that function has three different type arguments. You got to think about cause you, you hear arguments and you think of, okay, yeah, I'm just passing arguments to my functions.

Turns out in TypeScript, you can actually pass type arguments as well as runtime arguments, but there's an issue. If you pass like a type argument, let's say you're passing one to useState, for instance, you're saying this useState needs to take in a string. So that useState, it's got like an ID or something.

It's always going to contain a string. If you have multiple type arguments that a function expects, if you pass in the first one, then the other two won't be inferred from the runtime arguments. It like stops inference. And this is a massive pain because, and library maintainers have [00:25:00] been complaining about this for ages.

We had like nightmares XState. Because we wanted people to pass in certain things, like to specify different context or events that could happen on their state machines. But also we wanted the power to infer other stuff based on other stuff they passed in, but we can't, and... This actually, the TypeScript team admitted this was actually an error of theirs, just an oversight when they implemented like default type arguments, which was a feature they shipped years ago, they just said, I think Ryan Kavanagh, who's the lead dev for TypeScript, who just commented saying, we just rushed that out a little bit and we didn't think that we didn't think about inferring this stuff.

And now it's out there in the wild and we can't change it. But what they're trying to do now is they're trying to say, okay, if you pass in the first argument, You can pass in an underscore, a little magical character, into the second argument, and maybe the third as well, and that will try to infer there.

So it will basically say, okay, the feature that we should have shipped years ago. You can now enable [00:26:00] it just by adding little underscores. And they were thinking about shipping this for 5. 2, which is in beta as we speak. It might be out by the time this airs, but it didn't quite make it because there's just a lot of discussion.

And there's also TypeScript as well, where I go into this stuff. But yeah, so it's a very annoying thing about TypeScript that mostly affects a very small group of people library maintainers and such, but it does have a ripple effect out into the wild and out into people and our APIs get a little bit worse.

And I do wish TypeScript would fix it somehow. I'm not entirely sure this underscore method is the way to do it, we're getting there. We're getting there.

Yeah. Yeah. I understand the hesitancy to add more syntactical wizardry that you would never really know if you're like coming over from JavaScript. It feels like another thing. You look at a function signature and you're just like, What is that?

I don't know, like I've never seen that before, but I also understand why it would like the utility there. Is there a reason something like this couldn't be done in like a major version change? Okay, [00:27:00] we're finally ripping the bandaid off.

TypeScript doesn't do major versions. It does not do major versions. It doesn't do semver. It basically just goes minor version to minor version forever. That's why it went from 4. basically. So it doesn't ever do majors and it couldn't do a major.

I don't think like it's just not designed for that purpose. And I think it's basically a miracle. They've managed to just keep it doing minors for the past. 10 years, that's astonishing. Just basically continuing adding features. And that's why they're so circumspect about ever changing this stuff.

Because, when they make mistakes, those ripple out for a long time, and it's not clear whether like it requires a creative solution to ever be fixed.

Gotcha. Yeah. So is there, are, is the TypeScript team, is the project adhering to SemVerse semantics in that four to five? Is still a minor version. Like it has all of the I don't know the implications that a minor version bump would have there's not going to be any breaking changes.

Yeah, correct. There are, they do breaking [00:28:00] changes, but they're over a long period of time, and deprecated and they work with the community to try and get them over the bump and things. And they do an enormous amount of integration testing. So have you heard of the library or repository definitely typed?

Yep. Yeah.

It's like a massive repository for typing libraries that never had types basically. So if you have a JavaScript library, you can download something from definitely typed and it will basically type that library for you so you can use it in TypeScript. It's the biggest repo on GitHub by A country mile, I think.

Like thousands and thousands of these different sort of mini repositories in it. And TypeScript tests every version of itself against the entire thing. And like 20 other codebases as well. So TypeScript is continually making sure it doesn't break anything.

Gotcha. Gotcha. so we had someone ask . What is the best way to work with type declarations for external libraries?

Yeah, so I think there's like a few things there [00:29:00] like Often what you'll find is if you're using something that's like on the golden path like on lodash or Let's say react even because react doesn't have its own type definitions in its own library. You have to basically, when you install reacts, you have to install types react.

And those type definitions are updated, feverishly. They're extremely up to date and very well maintained and well looked after, but something that. Let's say hasn't been updated in a few years, or you're using something that's not quite as fashionable and doesn't have that many maintainers working on it, you might need to actually do some kind of patching of those declarations or like those types that come down won't be as good as you expect.

So this means that you start, need to start diving into d. ts files and d. ts files are declaration files. Every type that you put in a declaration file goes global, affects your entire project. And so you can do things in there let's say you want to be able to, this is a cool trick actually. Let's say you want to be [00:30:00] able to import I don't know.

CSV files in your project. What you can do is you can basically say, okay, I can declare module wildcard. csv, and you can actually give the thing that you're importing a type. This was pretty fashionable when we were all using a web pack directly. And we would, import PNG files and SVG files and all this sort of stuff, and we want to give them types.

Then this is the kind of thing that you can do in declaration files. TypeScript has a pretty good section on declaration files. I don't have much of it on Total TypeScript actually. But a lot of what you can do really is through declaration files, through putting things in the global scope. And I think that vaguely answers the question.

Yeah, I think so. I think so as well. Is there, like, how often do you find yourself dealing with these external library type problems, or is it I don't know, do you find it to be largely solved by the tooling at this point, or not that hard to get done?

It's so most of the time it's absolutely fine. I think often what you'll find is that [00:31:00] when you have a type error in your code, what you'll find is that the error actually comes from You not understanding quite what the types in an external library are doing. So there's like a mismatch between what you're trying to do and what the types say you can do in an external library.

And you'll often get these enormous great big errors where, it's saying, blah, blah, blah, blah, blah, blah, blah. It's not not assignable to a type or an interface you've never heard of or something. And so you need to go spelunking and diving around in these external type definitions. To really understand what's going on.

And you're going to see a lot of syntax in there that you're confused by, declare and namespace and all this different stuff, all these crazy interfaces and things. So being able to do that, being able to dive into that code, even if it's code, like that's typing the DOM, right? So there are like types that go into your project.

that tell you what DOM APIs are available to you, like mutation observer and window and documents and [00:32:00] all this stuff. And if you don't feel confident diving around those and understanding exactly what those types are and how they're related, then you're probably eventually going to run into errors and those errors are going to be super confusing to you and I think My guide for that would just be to get in there, just start looking around, start understanding, okay, HTML elements is related to audio elements is related to this is related to that and start understanding the flow of all of those.

Cause when I started doing that, I felt a lot more comfortable and confident sort of just working with the DOM and working with that stuff.

Yeah, no one asked us explicitly, but I feel like this is a common thing. People talk about when discussing TypeScript development issues is like those type error messages, right? Where it's okay, I've got some crazy complicated object and I'm getting some error and I look and blah is not assignable to some other thing.

And I can't even read it. The error message is like 400 lines long. It sounds like we're you're discussing demystifying that a little bit, but I, even I've encountered cases where I feel like I have a pretty good handle [00:33:00] on most of these concepts, but I'll go in. It's some type declaration.

It's like definitely a type file. It's like being auto generated by a library or something. And it's just like generic hell, right? There's there's no way a human wrote this. Cause it's just impartial. There's no, there's like, how do you, what do you look for in those error messages? Is there anything, any process you've found that does make that easier?

to get over that hill.

Yeah, so like an error message, you can think of it like a legal case. It's okay, you were here at this time in this city, you were here in this borough, you were here in this house, in this room opening this drawer with this hammer or whatever, without getting too graphic.

And It's basically, it goes from the widest scope possible into the narrow scope, and it then shows you exactly what the assignability error is. Really often, sometimes, what's going to be helpful is the really wide scope, and you want to look at the top of the error message to work out exactly what's going on.

Or, you want to look really narrow at exactly the thing, type number is not assignable to type string. [00:34:00] Oh, of course, I just need to put a frickin number in there and it'll work. Depending on, like often what I'll do is I'll just skip to the end, boring story, skip to the end, and actually see what the thing is doing and then I'll work up the error like that and get a sense for what the legal case was.

So it's okay, you're in this city, you're in this house, you went to the drawer, you got the hammer and then you killed the person, you know what I mean? Okay, I understand finally that I killed the person. Why do I need to sit for five hours to read this stuff? So that's. My tip for it really is just to work from the bottom upwards.

Don't be intimidated. Breathe the air. Start at the bottom. See if there's something there that you can understand. And then,

Yeah, exactly.

try to do a binary search of some kind and figure out where you're actually getting thrown off. Yeah, I think, like you said, it can also be helpful if it's not some crazy generic case like I was talking about before.

Just go look at the types. See what's expected. There's probably some. Like misunderstanding or like a bad assumption that you've made somewhere that can also be not that hard to discover once you're

[00:35:00] exactly And that'll pay off as well the more you understand the types that you're consuming because it's not just the runtime code that you're consuming these days You're consuming the types are part of the api that you opt into when you choose that library And so the more you invest in understanding those really the better time you're going to have, like it's just Nice and day between when you understand the types and when you don't understand the types because often you'll understand the types more and you'll understand the library more.

It's just like reading the documentation really.

Yeah. Yeah. Yeah, because there's a couple more questions in the dev space, and we'll wrap up with some kind of what's new on the horizon questions. But yeah, we said we'd work our way through the stack. So someone's asking about like PHP, a couple questions in relation to PHP deployment in particular.

And they're wondering how the pre processing works. Does it put a load on their PHP server? Or does it work only client side like JavaScript with no extra loader? Or it's The mix. And I think this might be hard to answer without a ton of context on what this project looks like, but in the wild, when you've [00:36:00] looked at like people that are working on this, what are those, how do those setups with PHP projects usually look

Yeah. So like mostly I think what this person is asking is, do I need to pre process the TypeScript into JavaScript every time I like run something? And the answer is no. What you do is every time you deploy, then you run TypeScript or you run ES build or SWC or something. You turn the TypeScript code into JavaScript ahead of time, and then you run those assets, right?

You just run the JavaScript. So you don't need to worry about that. Pre-processing being an overhead or anything, it's just something that you handle on Deploy. You can actually do it, in milliseconds when you use Yes. Build or something, and then boom, you're ready to go. I don't know about how it stacks up with PHP in terms of like actual performance, but really you are just comparing JavaScript to PHP at that point.

TypeScript isn't adding anything performance wise into JavaScript. It just doesn't, it doesn't change the JavaScript. It just describes the JavaScript.

Yeah. Yeah, in that same vein, we have someone asking about TypeScripts interaction with [00:37:00] the Dom and how it can be improved. They may be asking it this. phase. They may be asking more about debugging or something. But that when you saw that question, how can type scripts interaction with the Dom be improved?

What was your kind of initial

Yeah, I don't know. That's not a very clear one because I'm not sure whether they're, I'm not sure what they're asking, basically, they could be asking a ton of different stuff, but let's take it as let's take it as the simplest case possible, which is how does TypeScript help you work with the DOM?

And is it any good? And it gives you just a ton of. Typing's to help you work with the DOM. So document. getElementById, document. blah, blah, blah, blah, blah. It has native types for everything you can, you could encounter in the DOM. So let's say you're working with a list of nodes or something.

Like I always got confused between what was the difference between a list of nodes and an array of nodes or something? It'll just tell you, and it will give you an assignability error. And so it just makes, I find making with the. It makes working with the DOM a lot easier.

Cool. Yeah. I think that's most of the kind of, more Running code, deploy level stuff. So yeah, let's wrap up with [00:38:00] some TypeScript five questions. Someone was asking how they can migrate to version five safely.

As we said, there's no real major versions in TypeScript really. Like a lot of what you, like also TypeScript is really good because, if you, it's upgrading your test runner, like when you upgrade your test runner, what do you do? You just run test. And then you just test whether your test runner has broken anything.

Yeah, exactly So it's the same with typescript really I don't it doesn't tend to break a lot with with new definitions or anything Like let's say that you're working with an external library that has type definitions in it Often typescript if it's a big library often typescript will already have tested itself against that library, and It generally doesn't, it generally never deprecates features or removes features without a long history of deprecation.

So you're going to be pretty safe upgrading.

Cool. Is there anything cool at a follow up question? Was there, are there any game changing updates that were shipped and how can they improve development [00:39:00] flow with V5?

Yeah, so there's been like three versions since we last chatted. There's been like 5. 0, 5. 1. And 5. 2 is coming. I'm just having to wrap my brain to remember actually what got shipped in each of them. Because I've been in 5. 2 mode really making content about that for a while. Why don't we talk about that because that might actually be the one that's it's just been to beta and it's just Like probably going to be released by the time this comes out

Perfect. Yeah.

the main one that's there is the using keyword, which is a basically a javascript keyword or a keyword that's Gone to stage three in JavaScript, indicating it's ready to be put out into the world for further feedback.

And the way it works is it's like var or let or const. You can say using resource, let's say, and if that resource has like a, it's what's called a symbol dot dispose. If it has a dispose function attached to it via a symbol, then as soon as that variable leaves scope, let's say it's, a database [00:40:00] connection.

Then soon as you're done with that database connection, the variable leaf scope, then that dispose function will be automatically called by the runtime. And basically it'll just say. I'm going to close that database so you can, it gives you this really flexible kind of setup for, let's say, just opening a database connection and then closing it without needing to manually manage that, which is beautiful and really good for all sorts of stuff like file handles, WebSocket connections.

Bunch of different things. And so using is the one I'm really excited to try first of all. And it's it's actually comes from C sharp or they really heavily inspired it by C sharp, Oh, it's going object oriented again, but people loved it in C sharp. And I think they're going to love it in TypeScript too.

Have you heard of it?

Yeah. So I think that it's a good again, like it's always the crux of the object oriented functional thing. It's we live in an object oriented world, right? Like a database connection is a thing that needs to persist. So like at some point do you need, there needs to be that that translation needs to [00:41:00] happen, or like we need to figure out how to get from one to the other.

So I think having this kind of as a language Kind of primitive is handy. And cause there, there are often kinds where it's okay, I want to know as soon as nothing cares about this anymore, like it's probably lower level code, right? But I think that concept does end up cropping up in a lot of domains, like pretty frequently.

Just

I want to make sure this thing is closed. I want to make sure this resource is disposed of and it's just going to make things a lot safer, I think. And hopefully it'd be really nice to use.

Yeah. Cool. Cool. We've covered a lot in 40 minutes here. Yeah, is there anything else you wanted, anything you wanted to point listeners towards, Matt, or encourage them to check out?

Yeah. Check out total typescript. com basically. That's my one stop shop for for all sorts of stuff. So there's free tutorials on there for if you want to learn typescript, if you're just coming from a JavaScript background, you want to just like onboard really quickly. I like to make stuff that just respects people's time.

I don't really like courses that are like, here's 35 hours of content, like just do that and you'll be fine. I like stuff that's just pretty tight and [00:42:00] concise and interactive as well. So the way I like to teach is just give you like a minute of setup and then tell you a problem, try to get you to solve that problem, and then I'll show you my solution at the end.

I find that's really nice. And it's how I teach everything really on, on TT. There's also articles tips, all sorts of stuff for free. And then there's my paid course as well. Which is for education budgets and for when you want your team to level up and it's a really great way to just support and bring, if you're building a design system or building an app, let's say, and you want to get really good at TypeScript, that's what you go for.

Yeah, nice. Really well crafted education resource to be sure. It's always... Those are always good to see. And yeah, I appreciate the work you're doing, Matt. Thank you so much for coming on to answer these questions with me.

No worries. No, that was fun.

For sure. For sure. Yeah, listeners, if you have any specific questions about web dev, you can message our producer, Emily on Twitter at Emily K Kettner.

We might feature your question on a future episode. Thanks for tuning in.