1. 11
    Get TypeScript Coverage for Dynamic Parameters in Remix with Invariant
    2m 24s

Get TypeScript Coverage for Dynamic Parameters in Remix with Invariant

Kent C. Dodds
InstructorKent C. Dodds

Share this video with your friends

Send Tweet
Published 3 months ago
Updated 3 months ago

TypeScript is giving us a bunch of warnings. Let’s go through and correct some of those and get some type safety.

For marked we’ll just install @types/marked as a dev dependency. But, with our dynamic parameter slug it’ll be a bit trickier since if we rename the file it’ll change the param name and references to slug will become invalid.

To solve this issue we can use the library invariant, which we can use to check if something exists, and then throw an error if it doesn’t. This way TypeScript is happy since it knows that it’s impossible for slug to be null or undefined.

Then lastly we just define a LoaderData type for the data that our loader returns.

Kent C. Dodds: [0:00] TypeScript is a little angry at us and for good reason, we are not getting some type checking. We're not getting some autocomplete and things. Let's go ahead and solve that.

[0:10] First of all, "marked" is not typed, and so we're going to npm install as a dependency, types/marked to get the TypeScript definitions for "marked". Now, that's happy and getPosts is taking a slug, but that slug could be anything. At any moment, we could change this to postId and TypeScript doesn't know about our convention. It can't give us any help there.

[0:36] What we're going to do is use a handy little library called invariant. What invariant is going to do is it accepts a condition which will be used to determine whether something is defined. We can say, invariant(slug) and if slug is not defined, 'slug is required'.

[0:54] What the tiny-invariant library does is it will throw an error the message we've provided if slug is undefined. Because it does that, TypeScript knows that there's no possible way for select to be null or undefined in the following lines and so it's happy about that.

[1:10] We can do something similar for our post invariant(post, 'post not found'). We can maybe be a little bit more helpful by saying ${slug}. Now, TypeScript is happy with this.

[1:25] Then, let's make our LoaderData type. We'll say, LoaderData. We have title. It's a string and html is a string. Now, let's pass that to our json generic LoaderData. Then, we'll make this as LoaderData. Now, we are type checked.

[1:44] If we made some sort of typo or something, that would be type checked for us. We do have better ways of handling 404s, like this would be. We'll get to those eventually, but this will get TypeScript happy and able to help us a lot more than before.

[2:00] In review, all that we did here is we created this LoaderData which we used for our json generic, as well as our useLoaderData. That just took the title and the html. We also used invariant from a package called tiny-invariant to verify that the slug is defined and the post was found. With that, that made TypeScript happy and able to help us again.