>> Okay. So now we know how to actually render out a page on our application, but how do we go about linking from one page to another? Well, to get started with that within our routes file,

let's go ahead and add in another route definition. So we already have one per register, so let's add one now from login. We'll do async, ctx, and add in our route handler.

For this, we'll have this return ctx inertia render auth/login. The props that we were passing in here within our register, were just for demonstration purposes.

We'll be getting rid of that here momentarily. So we'll leave that out of our login altogether here. We can give that a save, open up our file explorer, scroll down to where we have our pages,

go into our auth directory, and let's right-click in there and add a new file called login.vue. Hide our file explorer back away. We'll add in our template element,

and let's go ahead and give this page a little header section. So we'll do a div class flex, flex call, space, y2. We'll add in an h1 to serve as our header,

text to xl font, we'll do semi-bold with tracking height, and the text for that will be login. Then underneath that, we'll have a paragraph with a class,

text small, text muted foreground. This is one of the utility classes that ShotCM Vue set up for us. This is where we'll want a link pointing to

our register page saying something like need an account register. Let's give this file here a save and a copy.

I'm going to leave the placeholder stuff that we have here, but I'm also going to plop it into this template as well, just so that we have it over here with an anchor link pointing to our login page instead.

The text here would probably be have an account and then point to login, and then the header text would instead be registered. Give that a save as well. With our server still running,

let's go ahead and jump into our browser. I'll do a little refresh there. Here is our anchor link going to our login page and then back to our register page. So although everything looks good,

we're actually not making use of inertia the way that we're using it currently. If we go ahead and right-click our document and inspect, let's dive into the console. Let's hide our errors, hide our logs, and hide our debug.

We're just going to leave XHR and request into our console logs here. We'll go ahead and click our login link now, and you'll see that we do a full get request for slash login,

and then all of our scripts come through. If we then click on our register link, you'll see that our page does a full get request for our register, and then we reload all of our assets there too.

The behavior that we would expect to see is that we would just do a get request for our new page and all of our scripts would remain intact and be reused for the new page that we're on.

Instead, we're reloading our full app script, and inertia is resetting, remounting our element, and everything. The reason that's behaving this way is because we're using a literal anchor element.

Now, just like with any client-side router system, inertia too has its own router system that allows us to easily go from one page to another using

the full benefits of inertia and our client application. So let's hide our browser away. For inertia, this component is called link, and we can import it from inertia view 3 just like so.

I'm going to make this bar here a little bit more 50-50 between our login and register page, and then we'll want to replace our anchor element with that link component just like so.

Let's go ahead and pop over to our login page now, and do the exact same things. We'll add in a script, setup lang, and set the language to TS for TypeScript,

and then we can import link from @inertia-view3. Jump down to our template and replace our anchor with the link,

and give that a save. Just like with anchor elements, the link component also works with hrefs to point to our target destination. So we don't need to actually change

the href attribute as that is perfectly valid for the link component here. With that change made, let's jump back into our browser now. Let's give the page a refresh so that we get a fresh console log.

You can see it looks the exact same as though we had clicked our anchor element prior to this change. We have our full register get request and all of our scripts needed to actually render out the page.

Scroll back down to the bottom of our console there, and now let's try clicking our new inertia link component to see what happens. So you can see we click that,

our page didn't do a refresh, and furthermore, we still see the old console statements right here from our initial request to our register page,

noting that we're now currently on our login page. If we scroll down, we see the get request for our login page,

but this is now an XHR request rather than a just straight get request, meaning that we're sending this out asynchronously, getting the result back,

and then inertia is updating our page accordingly. If we were to click back to our register page, you see that happens once more, we get just an XHR. None of the scripts are reloading,

those are all just being reused because we aren't actually reloading the page as a whole. If we were to take a look at our XHR get requests for the two pages that we went to,

our login and register pages, expand that out, take a look at the response. You'll see that this comes back with the updated component that we should use, the version, the props,

as well as the URL that we are now at. For our login page, you can see that it came with our props that are being shared with that page. We have shared globally and shared for middleware there as well.

Whereas if we scroll down and take a look at just a register page, you can see that this is coming with shared globally, shared for middleware, the same as our login page, as these happen for each and every page that we have.

Then we also have shared from route, which is shared directly from our route handler, and it looks like we have one more there being truncated. Yeah, stuff right there. With the inertia's link component, whenever we click on it,

it's really just going to send out a get request via XHR to the new page that we're requesting, and then it will return back just the information needed to

update our literal page for the request that we've made. If you recall back to the previous lesson, whenever we were taking a look at the inertia page state and use page as a whole,

we jump back into our view dev tools, take a look at the inertia page state. You see the initial page looks exactly the same as the information that we're getting back from those XHR requests.

Inertia is using the information from those XHR requests to update the page information that it has to keep that in sync and update our page render.

If we compare what we have here to what we have in our console, you'll see that they look relatively similar.