Passing Data Between Routes
00:00 We've got a new utility right down here called verification.server, and it's actually going to look a lot like our session server. So I'm going to copy that and paste it right here. We're going to use EN verification as the name of our cookie. These do need to be unique, otherwise they'll overwrite each other. Also, we want to set the max age for this because we want it
00:19 to naturally expire after about 10 minutes. So let's set that max age right there, and that is in seconds, not milliseconds as is often the case. So that's in seconds. With that now, I can come over to our signup page,
00:37 and here we want to bring in that. Oh, right, we also want to give this a unique name too. So we're going to call this our verify session storage. Okay, great. So with that, we can get our verify session, and that's going to be our verify session storage,
00:56 .get session, and from the request headers, get cookie, and we're going to await that, that's async. So with that verify session now, we can set the e-mail address that they specified for us.
01:14 So we're going to say verify session set, and we have this onboarding e-mail session key. We actually get that from our onboarding route. So our onboarding route is exporting this value, that way they can share that key in a really sensible way.
01:32 So that way we don't have this magic string, but those two things are supposed to be exactly the same. So we'll export it from this one and import it into here. So that's the thing that we're going to be setting. Then we need to commit this as part of our redirect. So we've got headers,
01:49 and set cookie will be await, verify session storage, .commit session, verify session. There we go. That is how we pass some data from our sign-up into a cookie, then we can read that in the onboarding, which we will do right now.
02:09 So when the user goes through onboarding, we're going to have a couple of requirements here. So to even show up on onboarding, they need to have that cookie in their cookie storage. If they don't, then they haven't gone through the sign-up flow yet.
02:28 So we'll just boot them out and we'll send them over to the sign-up flow. So what we're going to do, and we need to do the same thing on the action as well. So we're going to make our own little require function, like we've got here with this require anonymous. We're going to make a function we'll call require onboarding e-mail,
02:47 and that is going to take the request, and it's going to verify that the user does in fact have an onboarding e-mail and will return that onboarding e-mail. So we're going to get our verify session from await, verify session storage, .get session. Yeah, Copilot, I think you have the right idea.
03:07 Thank you. This needs to be async, of course. Then we'll get our e-mail from verify session, get onboarding session e-mail key. Remember, that's the nice thing about having this as a variable, is you can just reference them both and that works out nicely.
03:22 If the type of e-mail is not equal to a string or there's no e-mail at all, then we're going to redirect the user back over to the sign-up page because they shouldn't be here. They're probably trying to sign up maybe, but yeah, they can't onboard if they haven't gone through the e-mail flow.
03:42 Then we can return the e-mail if the e-mail does exist. So with that, we can now await, require onboarding e-mail with the request. With this now, we'll actually get the proper e-mail. So if I say cody at example.com, then we get cody at example.com.
04:00 So we've successfully taken some data from one page to another. In fact, I can even go to a new tab and that will be there. So this is already, we can demonstrate that this is superior to just using React State because I can go to a completely different page and that data is still there because it's inside my cookie.
04:20 So therefore, I should be able to go to my e-mail and then come back later and still have that e-mail address that I originally submitted. So that's handy. But it's not verification still, like we'll get to that later. This is just helpful in getting the data over to the right page.
04:40 Okay. So with that, now we need to get the e-mail out of the verify session. So let's get our, actually, we just did that with that verify session in here. So await, require onboarding e-mail. There we go. From the request, now we have the e-mail.
04:58 Then down here, we want to destroy the verify session. So once they've successfully filled out the form, we don't want the verify session cookie in their cookie storage anymore, that's unnecessary. So we can get rid of it. So we're going to get the verify session from the cookie.
05:17 Then we're going to, there are a couple of ways we could do this. We actually have a utility called combine headers. But I tried that and I just liked the way that this looked better. So we're going to make a headers object, and we'll say headers.append set cookie,
05:34 and that cookie will be this one that we had already. Then we'll have another headers append. Actually, yeah, Copilot, you're smart doing that expires date zero thing. But no, actually, we can do something even better, destroy session.
05:54 We just pass the session itself. Then with that, we can just say headers, pass the headers along. So you could use the utility if you wanted to. It is a handy utility. But for some reason, when I looked at it, I just thought this looked a little bit more clear.
06:13 So with that, then let's come up here. This is complaining about a type not being quite right here. Yeah, so let's take a look at our onboarding e-mail. Yeah, right here, we're returning a call to redirect. That's going to return a response. That is not what we want to do,
06:31 because this should only be an e-mail. This is why being able to throw responses and Remix will catch those for us is quite nice, because now this will only ever be an e-mail. Otherwise, it will be a thrown response. So that is awesome. Okay, let's review all the things that we did here really quick.
06:49 So our verification server or our file, our utility has our verify session storage. The unique thing about this is the max age. We set this to 10 minutes. So if the user doesn't finish verification within 10 minutes, then they have to go through the process again. You could, of course, increase this or
07:09 however you want to do that if you so desire. Then we have our sign-up page where we grab that storage and we set the onboarding e-mail, so that when we send the user over to onboarding, onboarding can grab it from
07:26 that session storage and use it for its loader and for its action. Then when the user has successfully submitted this form, we no longer need the verify session storage anymore. So we add a destroy session for that as part of the redirect at the end of that action.
07:45 That's one way that you can pass data between routes without having to use React State so that it can be persisted even if your browser tab is closed.