Current section: Testing Remix 4 exercises

Creating Routes and Context in Remix

Loading solution


00:00 So what we need to do is create another route, and this is going to be our root route, and it actually does need an ID because that's how we identify it. So we'll call it root, not rude, root. Remix actually gives an ID to our routes. We don't normally have to do that, but in this case, because we rely on that ID,

00:19 we need to specify that here. So then we're going to have a path, B slash, and our loader is going to have to be the awaited version of the return type of our root loader. So we're going to need to bring that in right up here. Import loader from our roots.

00:38 That's going to be around here somewhere. We've got a number of loaders in our app. It might be easier just to type it out. Yeah, let's just do that. As root loader from, and we'll just say app root TSX. There we go. So then this is going to give us some warning that says,

00:57 hey, you aren't returning the thing you're supposed to be returning. So let's return JSON. We need to have a fake version of all of this stuff that our root loader returns. So let's just copy this and we'll paste it right here. Then the username can be test.

01:15 All of this stuff doesn't really matter too much except for the user which needs to have not only the properties that we have from our fake user, but also roles specified. It doesn't matter what those roles are, so we'll just specify those as whatever. Then the theme doesn't have to be a real theme either.

01:33 It just needs to be light. That works. Toast, we can set that to null. ENV, we can just set that to mode test. Then our CSRF token, test CSRF token, and honey props. This one is a little difficult to construct ourselves, and so we're actually going to use

01:52 the honeypot for that. So const honey props equals honeypot.get input props. Then we can just use those like this. Great. Then the last step is that these two routes are not associated.

02:12 These are sibling routes, but we need this to be a child route of the root so that it has access to that data. We're going to add children with a lowercase n, and we'll move this as a child of that route. That gets our test passing.

02:30 So what we needed to do here was put this route that we're trying to test within the context of a parent route that has the ID of root, so that when we're calling this use optional user, we can get the route loader data for that route that has the ID of root.

02:49 Then we define that route loader data with this loader that resembles the root loader. What's cool about this is as we make changes to the root loader, we'll be reminded by TypeScript to come back over here to fix this over here as well. So that's a handy little thing that we've got there.

03:08 Then we define some children here. We have basically exactly what we did in the previous one, but because we are using the same user between the user that is returned from the root loader and the user that we're returning as part of this username route, we have the benefit of being the logged in user.

03:27 So then all of our logged in assertions will pass properly for us. So there you go. That is doing an authenticated integration test.