INIT
Episode 22: Typescript Fundamentals (Over)Simplified
Published:
Dude, in their recent podcast, Seth Whiting and Jake Pacheco totally drop some gnarly knowledge about their coding journeys and why TypeScript is, like, the ultimate wave to ride. They're like, TypeScript, it's this awesome superset of JavaScript that adds a chill layer of type safety to your code. Seth, he shows us how TypeScript makes declaring variables with specific data types a breeze, ensuring your data types are, like, totally consistent throughout your code. And let's not forget how TypeScript gets cozy with React, keeping your code stoked and error-free.
They dive deep into TypeScript's perks, man, highlighting how it amps up your code quality and snags errors early, with links to epic resources for devs. The talk gets into the zone where a top-notch team using TypeScript keeps the project communication slick and errors minimal, and they give some love for TypeScript over JavaScript.
And they wrap it up with some rad advice, telling you to catch the JavaScript, asynchronous JavaScript, React, and TypeScript waves. They drive home the point that practice and learning are the key to totally nailing these tech skills, making this podcast a must-listen for any coding enthusiast, bro.
(Auto-Generated) Episode Transcript:
[00:00:00] Seth Whiting: Hey everybody, I'm Seth Whiting and I'm a full stack developer from Portland, Maine, and I've been coding for about 10 years now.
[00:00:10] Jake Pacheco: And I'm Jake Pacheco. I am a barber from Augusta, Maine, and I've been coding for
[00:00:17] Seth Whiting: about seven months now. I think it's eight. Eight? Because we started in January. Yeah. Mid January, now it's past.
Late September. Yeah, late September. September. Sweet. Hey, look at me. Yeah. Yeah. I
[00:00:33] Jake Pacheco: mean, there's been, there's been some brief hiatuses
[00:00:36] Seth Whiting: in there. There's been some gaps. But yeah, here we are. Yeah. I say I've been coding for 10 years, but really like I started 10 years ago and then stopped for like eight years and then picked it back up.
Yeah, like, not really, like, I, I could
[00:00:50] Jake Pacheco: say eight months strong, but that'd be a lie. It's more like eight months weak. . I've been, I've been, yeah, coding for eight. Very, very feeble months. ,
[00:00:59] Seth Whiting: yeah. . No, I, I didn't actually take eight month, eight years off. No. If anyone was wondering. Cool. So today, What, what are we gonna, what are we gonna talk about?
What do you wanna talk about?
[00:01:13] Jake Pacheco: Yeah. . . I believe that we have some catching up to do with TypeScript. I don't think we've talked about it all. I don't even have a definition for it. . So, I think that we need to talk about TypeScript.
[00:01:23] Seth Whiting: All right. I think we gotta talk about it. So TypeScript.
TypeScript is. What's called a superset of JavaScript, which means that it's like all of JavaScript plus more stuff, and it's you, you write it in type script files. So instead of type jss, it's sorry, did I say type jss? Instead of jss, it's tss. Okay. And instead of JSX, it's tsx. And that will let your like computer and compiler and lint, linter, which we, I don't think we've talked about linters much, but we can and probably should this episode, they will all know that I'm looking at TypeScript here and I should interpret it as TypeScript.
So what TypeScript is, is basically it's JavaScript and you write it just like JavaScript. But you add certain things in certain places to make it what's called quote unquote type safe. And type safety is a big thing in a lot of languages. But that's kind of one of the things that sets JavaScript apart, is that it's like very kind of like willy nilly.
A lot of things can be interchangeable with other things and stuff. But TypeScript is basically an attempt to make JavaScript not so willy nilly and make it so that you force yourself to keep things very, like, neat and organized and kind of, you kind of box yourself into, if this, if this thing is a string or an object or a number.
It should always be that don't, don't make it so that you can change it, which you can do in JavaScript, like just straight up JavaScript, any variable, if you declare it as like a let, you can change it into anything else at a given point. Yeah. So does it, like, before I go any further, does this, is that making any sense?
Yeah, that kind of makes sense. I, so. Are we
[00:03:50] Jake Pacheco: talking, like, literally, you write everything in const, then, and, like, that way it is certain, and you're very, like, like, you kind of, you write something, and you mean it, in it, kind of a thing, I, and also, is this also, like, kind of, kind of like in React, when we talked about, like, oh, there's, like, it's kind of, like, In my brain, I'm like, it's rules to live by when you're, the way that you're writing everything and is this kind of similar in the sense where you're like, no, you're going to write things like this.
[00:04:22] Seth Whiting: And instead of
[00:04:24] Jake Pacheco: just like, cluttering it up with, like, your, all of your code with whatever you're writing, like, it, it all. It all is precisely written this way because it makes sense this
[00:04:36] Seth Whiting: way, kind of a thing. There, so as far as the, the first part of the question do you write everything in const and never use let?
No that's, that's just not, that's, that's not the case. I can see like why you would think that. And especially because like the example that I used but. But no, like, I'll, I'm sure I will make it clear by the end of this, like, what it actually is and how you actually do it. The second part of your question, you do, there is like specific syntax.
That you use sort of, sort of like, react where like you set things up in like the react way you with TypeScript, you set them up the TypeScript way but you use. You use both of them together and they, they work well together and TypeScript works well with like any JavaScript framework, yeah, that's, I was
[00:05:38] Jake Pacheco: just about to ask that, is like, okay, so am I, can I write Type script in react. I don't think I've done that before. I haven't done like a TSX file or anything like
[00:05:48] Seth Whiting: that.
[00:05:49] Jake Pacheco: So yeah, I guess what, what's the, is the big benefit just that it, it reads better to a human. Is that kind
[00:05:57] Seth Whiting: of a thing?
Good question. Yeah. So, so, I, I guess it sort of does read better because like, you know what you're getting into, but. There, there are some like huge benefits to it that, that we'll get into let me first just like kind of clarify what, what it actually is. So imagine declaring a variable and you could use let or const but you know, like I, like I said on previous episodes, I like to use const until I can't.
So like, if I know that it's not going to change, which I end up using const about probably 90 percent of the time, and then let 10 percent of the time, if that, it might even be less. If you have Just for example like using the Keeper app as an example, like if you have const reptile name equals,
Senku. You remembered. Yeah. So that would be in quotation marks, right? So like, because it's a string. So if you have const, reptile name equals Senku in, Quotation marks in JavaScript. That's that's, you know, the way that you would write it in TypeScript, the way that you would write it is const reptile name, colon string equals Senku in quotation marks, so that you know that the variable that you just declared.
Is a strain and should always be a strain. Interesting. That's that's
[00:07:44] Jake Pacheco: weird. Kind of. Yeah. So, so
[00:07:47] Seth Whiting: yeah,
[00:07:48] Jake Pacheco: so, Yeah. Okay. All right. What, what's the, again, it feels like the benefit is mainly to the reader, but again, like you said, we'll get into that, but but yeah, yeah. So I, I'm eager to learn more. Yeah.
The
[00:08:03] Seth Whiting: why. You have my attention. Yeah, you have. Now just tell me more. Yeah.
[00:08:08] Jake Pacheco: What's that other one? It's like you. You were intriguing.
[00:08:11] Seth Whiting: Now you have my attention. Yeah, it's like, Django,
[00:08:14] Jake Pacheco: I'm trained, I think. Yeah, Leonardo DiCaprio being a racist. Come on,
[00:08:16] Seth Whiting: man! Yeah, him, himself, not the character. Yeah, no, it's Leo. The actor. Okay, so, moving on. So, now we've got... Const reptile name colon strain equals in quotation marks senku. Next line would be const reptile age colon. Number equals six for, and then we can say like months, we can say that whatever number that is, is the number of months that they're there that they are just for example, and then we can say const, like is fed, for example, const is fed colon Boolean equals. True. Yeah. Yeah. So the check if it's true or false. Yeah. So you can see what we're doing here. It's like string number Boolean. Yeah. I'm trying to think of some others that are like basic. But I think I think then You start getting into like the more complex ones, just like, you know, if you, if you remember from like the the foundations of JavaScript episode, like way back episode, like four or five or something there are so many like, kind of like basic types of variables.
And then it gets like a bit more complex with like objects and yeah. And arrays, those are, go ahead. Sorry to interrupt.
[00:09:59] Jake Pacheco: So you're, so you're basically labeling your type of variable and then saying what it is, basically, or
[00:10:06] Seth Whiting: no, because like, yeah, yeah, yeah, yeah.
[00:10:09] Jake Pacheco: Like with number or string or whatever, you're, you're labeling them as this,
[00:10:14] Seth Whiting: Right.
You're like defining them as like, this is this kind of variable and will always be this kind of variable.
[00:10:22] Jake Pacheco: Interesting. Okay. Go on. Yeah.
[00:10:25] Seth Whiting: And then let's just for, for a simple example, we could say instead of reptile name, so like instead of const reptile name, colon string equals Senku, we could have const reptile names, colon string.
And then open and close square brackets, like the, the, what you use to create arrays, basically. Yeah, yeah. You put an open and close one after string. Yeah. And then equals, open, square bracket, senku in, in quotation marks, comma.
[00:11:05] Jake Pacheco: I don't know.
[00:11:06] Seth Whiting: DB Co. Yeah. Yeah. Comma, comma, comma. Yeah. Yeah. You know, all, all of your reptile names and then close square bracket. So, so that, that tells TypeScript that you are using that you're declaring a variable That is going to be an array of strings. Yeah, yeah. And
[00:11:29] Jake Pacheco: then, go ahead. Rewind real quick.
You said you would do array, and then the square brackets open and closed, and then equals open
[00:11:38] Seth Whiting: square bracket, and then. Names
[00:11:40] Jake Pacheco: separated by commas and then close
[00:11:42] Seth Whiting: square bracket. Ah, you do, you do so const reptile names, colon string, and then open and close square bracket, not so the open and close square bracket, take care of like the array part of it.
It explains it.
[00:11:59] Jake Pacheco: Hey, this is an array also kind of a thing because TypeScript.
[00:12:04] Seth Whiting: Open and close. Square, square bracket means, means this is an array. Yeah. Cool. Cool. So then you could have reptile ages, colon number open and close square bracket equals, yeah. And then so a number array,
[00:12:18] Jake Pacheco: and then, yeah. All righty. All right. Huh?
[00:12:22] Seth Whiting: So then moving on to objects. You can do Const reptile equals open open curly brace and then name colon string and then semi colon age colon number semi colon and then square close the curly braces.
Yeah. And then equals. Open square, open curly brace, name, colon, thank you, yeah, comma. And then age colon two or whatever, and then close curly brace. So setting up objects is like very similar to writing an actual object. Yeah. Yeah. It's not that far. You within your curly braces, you write like the kind of like sub variable, basically property of the object.
Yeah. Yeah. So name, colon string, age, colon. Numbers. Yeah. So, so yeah, I mean, it sounds
[00:13:29] Jake Pacheco: like you're writing it very similarly, just a little bit different. It's not like a crazy amount of different, but it's like, it's, it's more, like you
[00:13:37] Seth Whiting: said, concise, I guess, or more like, well, it's actually more of a
[00:13:41] Jake Pacheco: strict, yeah, it's more, yeah.
Yeah. It's more descriptive, I guess.
[00:13:44] Seth Whiting: Yeah. Better. So you end up writing more code. Yeah. But there, like I said, and, or like I alluded to, there are like a lot of benefits to it, like a lot. So. Then, just to get like, just to kind of like, put a bow on this whole, like, introduction to TypeScript here And then we'll move on to, to other stuff about TypeScript, but the, the way that you write TypeScript, you could have const reptiles colon.
And then you have your open curly brace name, colon string, semi colon age, colon number semi colon close close curly brace. And then open and close. Square brackets after the closing curly brace so that you know in an array there's an array of objects Okay, all right of this specific object. It's not just an array of any object It's yeah an object that looks exactly like this.
Yeah. Yeah, you see what I'm saying? Yeah yeah,
[00:14:55] Jake Pacheco: because you're calling to your in the beginning you called to exactly this and then you're like Now call it that, like that array that is, that is, that is in this format
[00:15:08] Seth Whiting: kind of a thing, right? Yeah, yeah, yeah. An object of like this format, there's going to be a lot of them in this array.
Yeah. Or like one or more of them in this array. Okay. Or it, it could be, yeah, , backpedaling and backpedaling. It could be that there are none, but if there are any, they should look like this. Yeah. That there are no objects in this array, but if there are, they should look like this specific object structure.
And if they don't
[00:15:35] Jake Pacheco: look like that, then don't pull it
[00:15:36] Seth Whiting: up kind of a thing. Close, close. Okay. It's, yeah, that's, that's sort of like where we're getting to. Okay. So. That's how you, like, declare variables. So we went through, like, the simple ones, where it's like, string, number, boolean, that kind of thing.
And then you can do an array of each of those, or you can do an object with each of those in it, or you can do an array of objects with all of those in it. So
let me okay, yeah, let me move on and then I'll come back to one other kind of point that's goes along with that, but a very useful, benefit to using TypeScript within the context of React is if you remember from previous conversations, when you have a parent component and a child component, you often pass Attributes, like you'll, you'll often pass props to your child components in the form of attributes.
So if you have like reptile list component, and then you have a bunch of reptiles as a, like a child component to each of those. So you have a a reptile child component. So it would be like open angle bracket, and then the word reptile with a capital R and then. Closing so like a slash and then a closing angle bracket.
If you wanted to pass, like, the name of the reptile into that reptile component, you would say so after the word reptile, you'd do space, name, equals, and then usually you'd open up a A pair of curly braces and say like name equals name, basically, if, if you're, if you have a variable named name, that's equal to Senku, or you could just do name equals and quotation marks Senku.
Yeah. And then within your child component file for that reptile. So like for the, the actual JSX component called reptile, you would access name via the props argument. Yeah. The component. Do you remember? Yeah. I remember this. Yeah. Cool. So what you can do with TypeScript. Is you can say basically your, your props in your child component, your reptile component, you can specify a type for what your props should look like.
So you could say props, colon, and then open curly brace name, colon string, and then close curly brace so that you know.
Whatever props are coming in, basically they should look like this. There should be a prop called name and it should be a string. Yeah. So within your child component, you can then access like props. name and display it in like an H1 or whatever, whatever, whatever, like, yeah, you know, HTML tag you want to display it in.
Yeah. And that way you can, and this is kind of like where it gets into like the, the linting stuff. And so basically you, if you're using TypeScript, you will most likely have TypeScript kind of like installed into your VS code so that it's like constantly checking these types all the time. So if you, if you declare, like if, if you do what I just said, where like the props on the reptile component should have name and it should equal a string, like it should be a string.
if you try to put in your reptile list. A reptile component, like if you try to insert a child component that is the reptile child component and you don't include name as an attribute, it will highlight it red and say like, Hey, you're missing name here, like you need to add that. That's cool. Yeah. That's kind of nifty.
And that's, that's actually like way more powerful than it sounds. Cause like they're oftentimes you'll have like a dozen or so props that you need to pass through. Yeah. You'll need to pass like half of them down another level to, to like reptile header, you know, or something like that, you know, so, you, it gets like very like, what's the word I'm looking for?
Messy. It gets like really messy really quickly. But if you have TypeScript, it's like, Hey, I got your back. Like you're missing this and this and this. Like you need to add those or else this isn't going to work out. Yeah.
[00:20:48] Jake Pacheco: It kind of, even if you don't know where you are, TypeScript has kept track of where you are, what you have and haven't done.
Yeah. So it's all, it's almost like a like a safeguard on making sure that you're typing your stuff right. And also being able to easily tell you where you type something
[00:21:03] Seth Whiting: wrong. Yeah. That's sweet. And I remember watching a video. By, I think, Ben Awad, or Awad, I'm not sure how to pronounce his name, but he's a YouTuber that I think a lot of people know but he was, he was basically saying like, if you're not using TypeScript, it's like It's like, you're writing JavaScript without the cheat codes and like, you're on like hard mode, but TypeScript just kind of like, like gets, you know, it like cleans stuff up for you.
Like it, it, it's, it's constantly checking for like, you're missing this or like you have this and you don't need it kind of thing. Yeah. Like, you, you included this, this attribute on your child component, but that's not specified in the props. So like, what are you doing kind of thing? Why is that here?
[00:21:52] Jake Pacheco: If you're
[00:21:52] Seth Whiting: not doing anything with that kind of thing? Yeah. Like, did you mean to put this here? Cause you know, you're, you're not, you're not expecting it basically in, in the component that you're trying to pass it into. That's cool. So yeah,
[00:22:04] Jake Pacheco: it kind of keeps you on track. With whatever you're writing it.
It's like, Hey, remember you were writing it like this. Keep doing that. Yeah. That's kind of sweet. Huh?
[00:22:12] Seth Whiting: Okay. Yeah. Sweet. Yeah. So, and, and then, so to kind of get back to like what I was saying before, when you're declaring your types, you also have the option const
Reptile, colon, open, curly brace, name, colon, string, age, colon, number. You could say age, question mark, colon, number. Which means if you're missing the, if you're missing the age, don't worry about it. Like some of them are going to have it. Some of them aren't. Don't, don't worry about it. That's cool.
[00:22:58] Jake Pacheco: Yeah. So how's that, how's that work?
I'm trying to think of like, is it technically like a boolean or boolean or whatever? Where, where it's like, where it's like, check if there's an age. If there isn't, then whatever. Or how's that, what, what is that called, I guess?
[00:23:13] Seth Whiting: Do you have a name for the question? Mark just says like, this is a, it, it, it basically equates to this is.
Number or undefined and either one is fine. Yeah. Okay. Cool. So it's undefined. Yeah. Don't, don't put the squiggly lines anywhere like, like it's fine. Question mark gives it leeway kind of. It's okay. That's. Yeah. Yeah. Right. Yeah. It can
[00:23:39] Jake Pacheco: or I can't have this and it's fine.
[00:23:41] Seth Whiting: Yeah. Huh. Interesting. And because of that, you could say in your, like, let, let's just say, Yeah.
That you made name optional. So in your child component, when you're trying to output the name into like your H one or whatever, so you, you make name optional and when you try to do props dot name, it's going to throw an error and say, Hey, this can be undefined. So you, you might not get. Anything here. So it will prompt you to be like props dot name or, you know, default to just like a reptile name, you know, in quotation marks.
Yeah. So like if, if there isn't a name here, we're just going to put, you know, the all Python or something.
[00:24:41] Jake Pacheco: Yeah. Yeah. Sure. Other things. Yeah.
[00:24:42] Seth Whiting: Yeah. Whatever is like the fallback. Yeah. That's cool. Yeah. I think, I think that's a legitimate. Example, but there, there's, there's definitely things like that where if you have an object within an object and this, this may be like a, more of like an actual example.
I don't know. I don't know if the example that I just gave is completely legit, but this is what I'm getting at. So if you have like, reptile. And then within reptile, you have like, like a sub object within the reptile object that says like schedule or something. And then it says like within the schedule object, it has like morning colon Boolean night colon Boolean.
And they can be, it could be like morning could be equal to true night could be equal to false. And it's like, that would mean that. It gets fed in the morning or not, and gets fed in the night or not, just as an example. Yeah. I have no idea if that's, you know, something that you would ever use in the actual app, but if you, if you made the object schedule optional.
Then you try to output props dot like, let's just say like your props are equal to the whole reptile object. So you could have a name, you could have an age, and then you could have a schedule that has morning and night within it. If you try to do props dot schedule dot morning, and like, if, if this, then do something.
If you just try to do that, but schedule itself, the whole object is optional, then it would be like, hey, you can't do props dot schedule dot morning, but you could do, like, you could do, like, If props. schedule, then props. schedule. morning. Yeah. That make sense? Like, you have to make sure that the schedule exists before you try to, like, use it.
Before
[00:26:57] Jake Pacheco: you try to,
[00:26:58] Seth Whiting: like, define it in any way or something? Well, before you try to use it in any way. Okay. Because if you didn't have that check, and you didn't... You didn't pass an actual schedule along with the reptile. Like if that, if that didn't exist and you tried to access something within something that doesn't exist, then it will throw like a nasty error on your actual webpage that people would be able to see.
Yeah. Or at least you would be able to see, and it would like stop you from developing on, on the actual site. It might like break stuff, but it might look not quite as bad. I don't know. Yeah. Anyway, it would, it would look bad in some way. It's not going to be
[00:27:40] Jake Pacheco: right. Yeah. Yeah. It's going to be bad. It's not going to be right.
[00:27:42] Seth Whiting: So it keeps you from. Yeah. Yeah. It keeps you from running into those errors. And, and in JavaScript, I can tell you before I started using TypeScript, I ran into that specific type of error a lot. Really? Where like, like I tried to access, like. Object dot object dot property a lot. And because you do that, you know, that's a very common thing to do, but ended up running into like, Oh, this second object doesn't exist.
Like so, so you can't, you can't access any properties of it. Like you're, it doesn't exist. So like, yeah. Yeah. Something that isn't there. Yeah. Yeah. Huh. Interesting. So TypeScript covers you there, which is nice. Any, any questions before I keep going?
[00:28:30] Jake Pacheco: A little bit like I know with VS code, there's,
[00:28:34] Seth Whiting: Was it.
[00:28:36] Jake Pacheco: Oh, forgive me. Is it ESLint? Is that what it is or something that that kind of looks for problems in your code or whatever? So I guess, is there, is there a big, I mean, you've, you've already said a lot of the benefits of using this over that. It sounds like you'd use this without ESLint pretty much because
[00:28:57] Seth Whiting: it's going to do it.
There's something called TS Lint. Oh, of course there is. Just to blow your mind. Oh,
[00:29:04] Jake Pacheco: man. Safety check on a safety check.
[00:29:07] Seth Whiting: Okay. The TS Lint is basically the thing in VS Code that is constantly checking your types. Okay. Does that make sense? Yeah. That's the thing that will throw the squiggly lines. That's the thing that will keep it from, yeah.
Yeah. Yeah. So
[00:29:23] Jake Pacheco: we are talking about, I'm so proud of myself for remembering ESLint. Yeah. But yeah, so it's, it's kind of the same thing, except this gives you a model to play by that is even
[00:29:33] Seth Whiting: more infallible
[00:29:35] Jake Pacheco: than just writing JavaScript and using ESLint or something.
[00:29:39] Seth Whiting: Yeah. Yeah. So, yeah. So, this, this so TSLint.
Basically covers the TypeScript specific parts. Yeah, yeah. Stuff, and then ESLint, you use them both, like the ESLint will catch like the regular, the more non TypeScript. Kind of like erroneous stuff that you're trying to write. Yeah. And then TSLint will catch the stuff where it's like, Hey, you're, you're missing, you're missing this attribute, you know, on, on this child component.
You, you need to add it because you've specified it in your, in your. And the actual components props. Yeah. Okay. All right. That kind of thing.
[00:30:19] Jake Pacheco: Yeah. Yeah. I was just curious about that. Because like when you said like at the beginning of this podcast, when you're like, we'll probably get into linting at a certain point, I was like, like ESLint, like,
[00:30:28] Seth Whiting: is that like
[00:30:29] Jake Pacheco: the same thing?
All right. All right. Cool. Cool. Yeah.
[00:30:32] Seth Whiting: Go on. So, passing it through. Right. As attributes to be accessed via, like, the props of the child component is one benefit where, like, it will check for that and and, like, throw up a flag and, and whatnot. But even within the same within the same file, you can, like, declare you could declare, like, an object, and then you could try to, like, loop through that object.
And it'll be like, Hey, this is an object, not an array. You can't loop through an object. Yeah. I think you meant to like make this an array to begin with, or maybe you meant to make an array of these objects. Like I don't know what you're trying to do here, but it's not going to work kind of thing. So yeah, there are just things like that, that it will, that it will be super helpful for.
Another thing is working with your like data that you're grabbing from the database, at least all SQL databases require you to, to declare types like for all of your like tables. Yeah, I remember that. .
[00:31:40] Jake Pacheco: Yeah. I, I remember that when we were working a little bit in Firebase Firebase. Right.
That was the Yeah. Database that we were, yeah. Where like when I was putting in, you know, my my objects or whatever, like, I, you had to specify
[00:31:52] Seth Whiting: each thing like that. Yeah. Yeah. Huh, interesting. Okay. Yeah. So that, but that's not, that has nothing to do with TypeScript necessarily. , yeah. . That's, that's just like, like I said, like.
I don't know about most languages, but I, I don't, I don't want to say most, but I kind of do want to say most other languages are type safe like this. JavaScript is sort of the outlier. But so basically like the, the fact that you have to do that in databases is not that like mind blowing because you have to do it even, even in a bunch of languages.
So anyway the point that I'm getting at here is. If you're working with a database and particularly like a SQL database, like Postgres or MySQL or something, then you, you kind of already know what types your data are going to present themselves in. And you, there are a bunch of different things called ORMs out there, which is object relational models, which.
Is basically like you set up your like database queries in a specific way so that you don't, you don't need to write like raw SQL code basically just makes, makes grabbing data and like posting data, like creating data and stuff more straightforward, easier to like read, easier to write And basically all of the, not all of the ORMs, but a lot of the modern ORMs are like, Privy to the fact that TypeScript is kind of taking over the JavaScript world, which it is, by the way, like, you, you will definitely be writing TypeScript on any, like, new project.
I don't want to say definitely, but... Odds are. Odds
[00:33:51] Jake Pacheco: are, yeah. The odds are
[00:33:52] Seth Whiting: good that, yeah. Yeah, yeah. Yeah, because a lot of people are like, oh, there's a lot of benefits to this and not much of a drawback. Like, you're, you're writing slightly more code, but it's for a good reason, you know? Yeah. Yeah. So, all of these ORMs...
Well, not all of them, but a lot of them are making it easy so that because you need to specify types for your database anyway, it's like, okay, just declare them. You were going to declare them anyway for your database. So just declare them here and we'll use them across your whole project. And you know, you don't need to worry about writing them, you know, in several different places.
Even though like you might, like if you were writing. If you're writing like raw SQL, you would type out the names of the types slightly differently. Like we can interpret that for you. Like we've got it. So just write the type and we'll use it across the whole project and, and basically, you know, that whenever you're fetching this data.
It should have all of these properties to it. Like it should look like this. And so when you're grabbing your reptile list from Firebase or wherever else, you wouldn't use an ORM with Firebase, you would use it with like Postgres and whatever else. So if you were grabbing your reptile list from, from your database, you know that each of those reptiles should be an object with a name and optionally.
A length, you know, and optionally a, you know, favorite food or whatever. Yeah, yeah. And then not optionally like an age, you know, like a requirement or like a birth date, you know. Yeah, yeah. So does that make sense?
[00:35:47] Jake Pacheco: Yeah, I think so. It kind of tees it up to be used everywhere. So it's not, you're not just writing it just for here, just for this.
Line of code that you're writing, you're actually writing it. So everything else can read it as well in a
[00:36:01] Seth Whiting: way. Yeah, that's cool. I didn't, yeah, nope. New news. So, yeah, so you, you let me go back to like the declaring of the the variables and stuff. So if you have const reptile equals open curly brace name, age, blah, blah, blah.
You could rewrite that so that above your const. You have type capital reptile equals, and then open curly brace age, name, age, string, name, number, blah, blah, blah. Yeah. So that below that you can write const, lowercase reptile, colon, uppercase reptile equals. And then your object with the, the name and the age and all of that stuff.
Okay. So you can declare just the type reptile as sort of like the, the same way that you would declare a variable. And then you could say like this variable is going to be equal to this type and you can declare and you can export types from one file and use it across your whole project. So you could say.
Whenever you're working with reptiles, you could just say, have a, like a types. ts, and you, you probably wouldn't, you probably wouldn't have just one types, file you would most likely have like a types folder. Mm-hmm. , and then have like capital reptile tss. Yeah. Yeah. And just have that be like a file with type like export type capital reptile equals, and then open the curly braces and.
You know, put all of their properties and their type information about that in here. Like the TypeScript types. Yeah. Yeah. From there. Huh? Huh? Interesting. Yeah. So across the whole project. You know, whenever you're working with reptiles, it, they should be this structure. Yeah. Yeah. It's kind of,
[00:38:13] Jake Pacheco: like what you just explained, it reminds me a little bit of like that, the button thing that you were, that you had explained before, where it's like, you can just set it up in, in, you know, multiple different files.
Oh, you don't have to keep editing it or writing it in a bunch of different pages. You can just be like, you can just call to pythons and then the pythons it populates with the pythons information and earn.
[00:38:35] Seth Whiting: Enclosure size or whatever it is. Well, it would be like the, the types for that python. So like, oh yeah, you would probably say like pythons so like export type pythons.
And then equals, and then you can extend types. So you could do python like type python equals reptile. And then, and. Like the and symbol and then open curly brace like diet or whatever, whatever would be specific to just Python diet probably wouldn't be one of them, but like pattern or, but I mean, yeah.
I get
[00:39:16] Jake Pacheco: what you mean though. Yeah, yeah, yeah. Or locale or something. Yeah. There, yeah. There could be a bunch of different
[00:39:21] Seth Whiting: things. Yeah. That's cool. Yeah. So you could have like your more generic and reusable reptile object and then you have an object for Python for lizard. You'd have, yeah, like, yeah. Yeah.
[00:39:35] Jake Pacheco: It's kind of like having like. And have like your genre and then your subgenre and then your, yes. I don't know what, what's below subgenre?
[00:39:42] Seth Whiting: Your sub subgenre. Sub sub . Yeah. Yeah. Yeah. Yeah. That's cool. Yeah. Neat . Yeah. And so another, another cool thing about TypeScript is that. In your command line, you can just run TSC and you have to install this, but if you run TSC, it will scan your entire project repository and say like, Hey, and this one random file that you haven't touched in like a while, you're, you're using like this component that you just updated to.
And you just updated it so that you, you require a certain prop that you didn't require before, like in this old file, you, you wrote that before and you, for like, you, you didn't use that prop, you didn't use that attribute because it wasn't a required prop before, but now it is. So go back and update it with the required prop.
Does that make sense? Yeah. Yeah. Like you now require the name for the reptile, but on like this, like. Other list, not like your reptile list that you've been working with, but someplace else you know, this old file, you don't have the name. You're not passing the name through to, to the, the child component.
And is that
[00:41:03] Jake Pacheco: basically, it will still run for the current list, but there's not the other one. And, but it's kind of letting you know, like, Hey, by the way, you didn't do this. Do you want to do this? Yeah. And, and you can choose whether or not to. Change it or
[00:41:16] Seth Whiting: whatever. Yeah. And, and it all compiles to JavaScript.
So like whatever you can get away with in JavaScript, you can get away with in TypeScript. It's more just like alerting you, like, Hey, telling you everything. Yeah. Yeah.
[00:41:28] Jake Pacheco: That's cool. So it's kind of, it's, it's kind of like, like. You do something, and then I'm here, double, like, saying it again, like, like this?
Nah. Bad analogy. But I just mean, like, in the sense of, like, it's kind of repeating back to you what you've written.
[00:41:46] Seth Whiting: Because in code,
[00:41:48] Jake Pacheco: sometimes it's, you know, lost in the sauce kind of a thing. There's a lot there. And... And maybe you forgot something in the past. So that's, that's pretty sweet though. That, that's, that's cool.
I didn't know that that existed. I thought the only thing that we had was
[00:42:02] Seth Whiting: ESLint. Right. Yeah. So it's, it's super useful. I mean, like the, for that specific example, like, like imagine you had like the reptiles, the reptile component, and before you weren't requiring, like, you weren't requiring, Like their species, but you were acquiring their name, but not their species and in your reptile component you Are now displaying their species like pretty prominently Below their name.
Yeah, and you weren't always doing that Like you've used this component before in like a bunch of different places But you just updated that component so that it's displaying that prominently. So you're going to want to make sure that you're including their species everywhere. Yeah. But you're not in like this file that you haven't touched in like a while, you know?
Yeah. Yeah. Cause like it's out of sight, out of mind, whatever. Yeah, exactly. So when you run the, the TSC command, it's like, Hey, like you updated this component, you're using it over here, but you're not using it the way that, you know, you just specified that you wanted to use it. So. Huh. That's cool. Yeah. So yeah, that's,
[00:43:17] Jake Pacheco: that's wicked cool.
[00:43:18] Seth Whiting: Yeah.
[00:43:19] Jake Pacheco: Yeah. It it keeps you on track
[00:43:21] Seth Whiting: with everything, right? So like on that, in a lot of ways on that component where like, you're not passing the species, like it would display the reptile component, but it would be like, there would be like a big gap there or even worse. It might say like the word undefined there, if you read it in a certain way, it'd be like, you know.
Less than ideal. Yeah. And this like keeps you from doing that, which is cool. Yeah, that is
[00:43:51] Jake Pacheco: cool. Yeah. So, so I, then I guess do you not really write a lot of JSX files in general? Like, is it, is it more that you write most things in
[00:44:02] Seth Whiting: TypeScript? Yeah. So on a project, on a project. That you are using TypeScript, you will generally, like, avoid writing JavaScript wherever you can.
[00:44:14] Jake Pacheco: Yeah, yeah, yeah, because what's the point? Like, there's not really a, is there
[00:44:19] Seth Whiting: a benefit to it or anything? To writing just JavaScript? Like, there may be certain use cases where, like, you should still use JavaScript. Yeah. I just, I just
[00:44:31] Jake Pacheco: imagine like this nineties grunge guy that's like, ah, he doesn't play by the rules.
He writes everything in
[00:44:36] Seth Whiting: JavaScript. Well, so like people still do write JavaScript and actually like there's some like big hoopla now of like, I think it's spelt documentation or not their documentation, but like. Svelte itself, they used to be written in TypeScript, but they just like rewrote it all back to JavaScript because of like certain, certain reasons.
Like it basically like makes it harder for people to like contribute to Svelte itself. I think it was Svelte, it could have been something else, but it is, you know, it's, it's, it. It's sort of a speed bump, you know, in development, but specifically when you have like a hundred people, not a hundred, like several hundred people working on a project, like a big open source project.
Writing types for everything can get pretty cumbersome, like, because things get really complex and deep and like nested, like several levels down and you need to cover all of your bases. Like, if you're going to cover any bases, you need, you need to cover all of your bases. And like, if you're using TypeScript on a gigantic project, like.
Your types are going to be like, they're going to need to be very like reusable and adaptable and blah, blah, blah. And making them that way. Like if you get deep and then like nitty gritty of like, of TypeScript, like the, the kind of like get in the weeds with it, it gets really. Confusing and like hairy, but the, the vast majority of TypeScript that you're going to be writing is just what I'm talking about.
Yeah. Yeah. Kind of like
[00:46:27] Jake Pacheco: smaller projects
[00:46:28] Seth Whiting: too. It sounds like it's like, it's just like you and a couple other developers. Yeah. Yeah.
[00:46:33] Jake Pacheco: I mean, but then again, I could definitely see like the benefits of like having, you know, a hundred person team on, on a project and if they're all writing TypeScript and they're all.
Good at it, I guess, then maybe I don't know that Seth did this here. And so I just type something and it's like, Hey, by the way, this just, this happened over here. So you might want to check that before you continue. I could see how that could be handy. Like, you know, versus JavaScript where maybe you're just having an error message and you don't know why you're.
[00:47:08] Seth Whiting: Yeah. Yeah. No, I mean, it's super handy, like for, for, you know, most. Most projects and whatever like all of that is to say, like, I will pretty much always use TypeScript over JavaScript just because I, I've been using it for a while now. I'm comfortable with it now. And I see a lot of benefits in doing so.
But I think they're probably not probably, I'm sure. And I know that there are like. Senior developers out there who have used TypeScript and just don't like it and would rather use JavaScript, you know, yeah, it's just like a preference thing. Yeah. Preferences. There's also like it's worth mentioning, I guess, that there's something called flow out there, which is like a TypeScript replacement.
Like they kind of came out around the same time and TypeScript just kind of won the competition there. Yeah. Yeah. And so, yeah, I don't know if you're, so that exists also,
[00:48:15] Jake Pacheco: have
[00:48:16] Seth Whiting: you used it? I haven't used it. No, no. Do
[00:48:19] Jake Pacheco: you know anyone that does that's that's like a flow flow guy? I don't.
[00:48:25] Seth Whiting: Yeah, no.
Interesting.
[00:48:28] Jake Pacheco: Yeah, so I guess that should be something that I should learn how to write
[00:48:33] Seth Whiting: things in. I'll tell you what, it's,
[00:48:37] Jake Pacheco: it's impressive. It's impressive. Every time you do it, would you just like start rattling off exact code, like, Like, it's, it's, this is a language, folks, and Seth knows the language, like, it's, it's, it's, cause it's like another language, it, it is another language, it's like, you're like, yeah, like, this, and it's like, yeah, okay, buddy,
[00:48:59] Seth Whiting: yeah, it's, I mean, this is what I do 40 hours a week, every week.
I just have to
[00:49:06] Jake Pacheco: like, yeah, I just have to like shut my eyes and imagine like the code populating. Yeah, I mean, hopefully there
[00:49:12] Seth Whiting: is like, yeah, hopefully it's like clear enough to like picture. Yeah. Yeah. I mean, well, that's
[00:49:18] Jake Pacheco: why like I, I ask again on certain things and stuff. Ask us to rewind a little bit just so I understand fully.
And hopefully that helps anyone else. If they have a I don't know what the word is. Like if
[00:49:30] Seth Whiting: they missed something.
[00:49:31] Jake Pacheco: Oh. Like, well, just my brain's all over the place. Yeah. , you know, it's like, so if they're like me, where, you know, right. A A A D D, I guess is what we used to
[00:49:40] Seth Whiting: call it , so Yeah. Yeah.
There's an H in there somewhere. Yeah. Yeah. I'm
[00:49:46] Jake Pacheco: not that hyper though. I'm quite tired. , but I, but yeah. So yeah. At, at the end of the day, TypeScript, it, if I were to define it, would be like a,
a way to find any error in it. It, it's, it's, it's a way of writing. They makes errors a lot more apparent mm-hmm. In what you're writing.
[00:50:09] Seth Whiting: Yeah. Kind of. Yeah. Yeah. That's a good way to think of it. Yeah. Yeah. A way of writing that. Yeah.
[00:50:14] Jake Pacheco: That's cool. That's, that's, I didn't, I, I didn't realize that there was another, you know,
[00:50:20] Seth Whiting: yeah, it's like a whole other like layer.
Yeah, to
[00:50:23] Jake Pacheco: the, to the cake, the, the, the big cake that I'm trying to eat one bite at a
[00:50:29] Seth Whiting: time. Yeah, it's just like another, another like tool in the arsenal that like makes Writing code, like a sort of like a bit easier for people to like, not mess up, you know, yeah, yeah, a bit.
[00:50:44] Jake Pacheco: Yeah, a bit less troublesome. I when you're writing it, it sounds like like where it's like, ah, like, as long as you write it like
[00:50:52] Seth Whiting: this, and you're using I
[00:50:55] Jake Pacheco: tslnt, tslnt,
[00:50:56] Seth Whiting: then
[00:50:57] Jake Pacheco: I, then.
You're you're kind of protected. Yeah. Another layer of protection against yourself.
[00:51:02] Seth Whiting: Yeah. Yeah. So, it kind of, and it's like a good, a good way to avoid having to write like a bunch of tests. So like, a lot of tests are like, you know, check, check if something exists or like, check if like this component.
Includes like when you render this component, does it have a title? Does it have a, you know, whatever else you don't, you don't really have to check for that kind of stuff. Cause it's
[00:51:33] Jake Pacheco: already checking in the background for you the minute you wrote it. That's cool. Yeah. That's wicked cool. Yeah. So, yeah, I mean, I, that, that makes perfect sense.
Right. People would write things in that.
[00:51:45] Seth Whiting: Yeah. And now we know, you know, yeah. Yeah. So that's that's TypeScript in a nutshell. I think I covered pretty much whatever it was like, pretty much what I wanted to cover. Like there's definitely a lot more to it. I'm sure. But that's sort of like the day to day, like what, what you would need to know about TypeScript.
Well, I guess like one last thing to know about it is like, there's sort of a way to cheat and that's when people use the word any. So if you say like reptile name, colon, any equals, you know, Senku or whatever, that's basically just saying like, don't. Don't check my work, TSA. Like, it's just like You can kind of circumvent it, if you need to.
Yeah, if you need to. And that's sort of like, how you know somebody is unfamiliar with TypeScript is like, well this thing was yelling at me and So I just wrote any to get rid of it? Yeah, it's like, I wrote And that seemed to make the error go away. So I think that's good, right? Yeah. and then like No,
[00:52:56] Jake Pacheco: you got rid of all the checking ,
[00:52:58] Seth Whiting: right?
Yeah. The, the whole point. The person who's been writing TypeScript for a while would be like, no, you have to like specify, like you have to, like, the whole point of TypeScript is to specify Exactly. You know what this is going to be. Yeah. Why
[00:53:11] Jake Pacheco: even write it if you're just gonna circumvent it all and like not Yeah.
And render it mute at that point. ,
[00:53:16] Seth Whiting: right? Yeah. So that's, that's That's just something, like, something that you will see in the wild. And it's, it's, there is like actual, there are actual legitimate use cases for the word any in TypeScript. So that's like why they leave it in there. But it tends to get overused by people who are, especially people who are like just learning TypeScript or like thrown onto a project with TypeScript when they're used to just writing JavaScript and they're, they're like.
Basically just like getting used to it and like
[00:53:51] Jake Pacheco: just, just running through the mud, just figuring it out. Yeah. I mean, I feel like for me after hearing you explain all of that and everything and like kind of having a grasp now of what TypeScript is and stuff, like I'd be like, I'm never using any just to like see, you know, like I, cause I shouldn't have to, I should be able to figure it out.
I should be able to Google or figure out like, Hey, how do I write this? So it works or something. Cause yeah, like
[00:54:18] Seth Whiting: what, what I, like
[00:54:21] Jake Pacheco: you said, there's cases where you need to use
[00:54:22] Seth Whiting: it or whatever, but, but it seems like a lot of the time you shouldn't write it. There's a, an ESLint rule that you can set, or I guess it would be a TSLint rule.
That you can set that's called no explicit any, where if, if it sees any in your code, it'll highlight it and be like, did you mean to write any and it'll basically like stop you from. So one, I guess one other thing I should mention is that in, in our episode where we were talking about like how to deploy.
A web app or a website, like how, how to make it public. We were talking about the concept of CICD, which is continuous integration, continuous delivery. That's like when you push your code to a certain branch, it'll like kick off a process on your like host that will build your app for you and then. Say like, okay, this is the new version that people should see basically.
Yeah. So within that build process, you can specify that you want it to run TSC, like the, the TypeScript, like the TypeScript checker, and it will go through your whole project and just make sure that there are no TypeScript errors in your whole project. And if there are, it'll be like, okay, we're not going to make this live.
Oh, that's cool. Like fix this first. So
[00:55:49] Jake Pacheco: TypeScript also
[00:55:50] Seth Whiting: adds that as well, kind of. Yeah. It can if you, if you, if you make it,
[00:55:56] Jake Pacheco: if you want to quadruple check your
[00:55:57] Seth Whiting: stuff, you can, you can check it locally on your, on your computer, like whenever you want by running TSC, but you can also add that in your, in your like pipeline process to where it won't, it won't actually push out any code unless it's been.
Well, that, that
[00:56:20] Jake Pacheco: kind of makes sense because say like, I didn't have TSC running on mine and you have it on yours and, but you set it up so it has it built into that so that when I push something, it doesn't automatically go, you're kind of double checking at first to see, okay, is this good? Right. If it, if it isn't because, because Jake's thumbs get big sometimes then,
[00:56:44] Seth Whiting: then yeah, that makes sense.
Huh.
[00:56:47] Jake Pacheco: That's cool. Well,
[00:56:48] Seth Whiting: that's kind of cool. Yeah. Yeah. Hey,
[00:56:51] Jake Pacheco: TypeScript. . Yeah. JavaScript, J sx, TypeScript, all all of it. Dx. All this stuff. Yeah. D Ss X,
[00:56:58] Seth Whiting: all of it. Yeah. All of it. It's cool. Yeah. Yeah. Cool dude.
[00:57:03] Jake Pacheco: The plot thickens.
[00:57:05] Seth Whiting: Yeah. Yeah. Another thing for you to learn. Another thing to learn. Yeah. But like I said, you know, that's most of it.
And if you, if you comprehended all of that, then you're in good shape. If not, like, and, and I'm sure that you didn't internalize all of it. There is a TypeScript course on Codecademy that you can take. Yeah. So you take that and that'll get you thoroughly, you know, like in, into TypeScript and drill it into your head and, you know, make sure that you actually understand all of it, which is great.
Great. Yeah. I'll look into that then too. Cause yeah, I would say do do like if, if I were advising like anybody on like a track of what to do, I would say like, do do JavaScript, like intro to JavaScript and do at some point do the asynchronous JavaScript one. Definitely get that one under your belt and then, then you could do either react or TypeScript, whatever order you want, you know, that's probably the order that I would take.
Actually maybe, maybe do those before the asynchronous one doesn't really matter. It's basically like get the JavaScript one under your belt and then do either async. Or React or TypeScript, but you should probably do all of those because you will use all of those for sure. If you're working on like a big modern project.
Yeah. At least a React project. Yeah, yeah.
[00:58:42] Jake Pacheco: I, I, we, we notice it. I think that that's kind of implied with our, with our show at this point. It's like, Hey, we're talking about React. We're talking about JavaScript. You know what I mean? We're not, we're not teaching Python here. You know,
[00:58:53] Seth Whiting: or, or just about Angular or anything.
Yeah. Yeah. Yeah. Cool. Sweet.
[00:59:00] Jake Pacheco: Hey. Hey, hey, hey. Hey, hey, hey. Yeah. Sweet. Well, yeah. Anyone who's listening. Thanks for listening. I hope to hear from you on where we have a few episodes on YouTube now, I believe at this point. And and yeah, so
[00:59:18] Seth Whiting: the, the most positive place on the internet. Yeah.
Yeah. Hit us up in the comments and be
[00:59:22] Jake Pacheco: really nice, please. We'll see. Yeah. Someone's going to say something, right? Alrighty. Well, again, thanks for listening. Thank you, Seth. And you'll
[00:59:32] Seth Whiting: be super, super busy, but, you know, just try to squeeze in like an hour at some point, that would be, you know,
[00:59:41] Jake Pacheco: how do you, how do you eat an elephant one bite at
[00:59:43] Seth Whiting: a time? Yeah, just keep at it and you'll. You'll you know, build up the, the experience and the muscle memory and all of that, and everything will fall into place over time.
It's going to take a lot of time. So just keep at it. Cool. Alrighty. Thanks again. Have a
[01:00:03] Jake Pacheco: good day.
[01:00:04] Seth Whiting: See
[01:00:04] Jake Pacheco: ya. See ya.