Intermediate React, v5

Typing Modal Component

Brian Holt

Brian Holt

SQLite Cloud
Intermediate React, v5

Check out a free preview of the full Intermediate React, v5 course

The "Typing Modal Component" Lesson is part of the full, Intermediate React, v5 course featured in this preview video. Here's what you'd learn in this lesson:

Brian begins the TypeScript migration with the Modal Component. The component file is renamed to a tsx extension which triggers the TypeScript checking. Types are added throughout the file to eliminate type errors.


Transcript from the "Typing Modal Component" Lesson

>> Okay, so we're gonna start on Moodle.JSX. So, the way that you want to do a migration from a JSX to a TSX codebase is you just say everything that is not in there does not have a TSX file, is not strictly checked, right? So I'm gonna go here into MoodleJSX and I'm just gonna modify this from JSX to TSX, right?

And then all of a sudden I'm gonna start getting a ton of errors here of like, hey, you need to fix this, right? Okay. So I'm just getting a bunch of type TypeScript here. Like HTML development is not assignable to type nu that these are all good errors for us.

So, let's just start, piece by piece going through this. Get rid of react there, because we're not using it. Use effect, use ref, we're gonna import mutable, object ref, and react element from here And that all looks good. We're gonna say that children here are they are react elements.

That's a return type, not out. Actually, what we wanted there, inside here, rather, okay? So, the first thing we're gonna say here is these children coming in from as properties. They're gonna be react elements. And react elements is basically anything that react can render, which is gonna be something of either JXS type.

It could be a null, it could be a bunch of stuff like that. So now we know if you mouse over children, we know that for a fact this is a react element, which is cool. Okay, next thing we're gonna say is this eLRef here is going to be a mutable ref object, which we have up here, right?

But we're gonna tell it what type of thing it's going to contain, and it's either going to contain an HTML div object. So HTML div element or you can see here we instantiate with null, so we have to say or this is null. Okay, and then now if I mouse over L ref, I can see that it's either an HTML div or it's a null.

And so that means here that's what I have to do this check here. Now you can see here that every time that I refer to eLRef.current, I can be guaranteed every single time after this point that it's going to be an HTML development which is great. Cool Okay, let's go down to our use effect here.

First thing we're gonna say here is, every time that you query the DOM for here from Get Elements by ID, it can give you back null, right? Just in theory if the HTML doesn't have modal element, it's gonna be null, so we have to be defensive about that and say if modal route or No eLRef.current.

Then here we're just going to say return, right? If either one of those doesn't exist anymore, then we're gonna be just say, 0kay, well, no, we're not going to do that. Now I'm guaranteed here that model is definitely an HTML element because if it was null it would not get past this point.

So that's why that works. Here we have to again be a little bit more defensive here, and this return function here. So we just have to say if there is no modal route, or rather, if there is no eLRef.current. Then, if there is, then go ahead and remove it.

There we go, okay? And now this Model.tsx looks good. So all of these, if statements you're gonna find here, this is very common theme with particularly when you're porting an old JavaScript type code base where you can be kind of loose with your types, right? Here I wasn't being defensive about model route never being there because I literally wrote the HTML that has it there.

So I'm not really concerned about it being removed, right? It's that therefore I was not very defensive about it, but TypeScript is going to be making me very precise about. Nope, we have to provide for all the cases because we do not allow runtime errors like that Cool Any questions about this makes sense All right, so that is modal.

Now the question you might ask me is, how do I decide what order to migrate files to? The easiest thing to migrate is model itself doesn't really depend on any other of my code, right? It's kind of a leaf node in the sense of this modal is not importing a bunch of other stuff.

Therefore, it makes it a good candidate for me to type. Because once I finish typing this, you can see this actually has no errors anymore, right, because it's not importing anything that doesn't use TypeScript. As opposed, if I went and typed app.jsx for a moment. This imports from adopted pet context from details from search params, so even after I finished migrating these files, I would still have type errors, right?

Because these are untyped therefore the strict type checking from TypeScript is not going to allow these to go without an error. It's fine, you can still do it but, I like the fact that I'm done with modal.tsx here and I'm totally done with it. I don't have to do anything more for it.

This is totally free of type errors. If I go do app right now, I'm gonna finish it and there's still gonna be type errors, which is less fun, I suppose.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now