Now, linking between pages is a very common feature for every single web application to have. So it may not be in our best interest

to have one of those imports for our link component in every single component where we need to link from one page to another. Instead, what we can do is register it globally,

similar to our unplug and view component behavior, so that it is readily available throughout our entire application as we need it. As a reminder, that unplug and view components

is looking specifically inside of our components directory for components to automatically register globally. It's not looking inside of the InertiaJS package with how we have it set up.

So any usages of our link component will not be picked up by that, hence why we would need to register this manually ourselves. So to do so, what we want to do is jump into our app.ts file

inside of our Inertia directory. And just like any view application or whatever front end it is that you're working with, you'll want to first import the component that you wanna register globally.

And this is from @inertiajsview3. And then just register that globally the same way that you would inside of your client side app. So right down here,

we are instantiating and mounting our view application. So this is where we're going to want to do that. So we can do .component, provide in the name of how we want to register this globally.

So link right there, and then provide in the actual component that we wanna use with that name, which is our link component. Now we're not quite done here yet, but we're gonna go ahead and pause here

so that we can see exactly why it is we're not quite done. And then we'll go ahead and jump into our register, and we can remove that link import from our setup script,

essentially deregistering it inside of this specific page. And we'll leave the implementation inside of our template. We'll do the exact same inside of our login page,

so we can just remove that import altogether and hit save. Okay, let's go ahead and jump back into our browser now, and let's give it a go. So we'll do a refresh here for sanity sake,

and then we can click on our login link and our register link and everything there is working A-okay. Furthermore, if we right click on it, inspect, go into our console,

we'll circle back to these errors and warnings momentarily. What we wanna do is make sure that this is still being used as an inertial link rather than a straight anchor. So we'll hit login once more,

and you can see it doesn't XHR request rather than a full non-asynchronous request. And the same there whenever we click our link again. So it is still behaving as an inertial link.

Now back to those warnings. So let's do a full refresh here, show our warnings and errors again. And this is why we're not quite done. You'll notice that we have a warning

for hydration node mismatch. This is that hydration mismatch that we've been talking about thus far. This is just an example of it in practice now. Now what this warning is doing

is it's telling us specific usages where the hydration mismatched. So we can see specifically that on the server, it rendered out as an empty string,

but on the client, it expected a button. And then we get a call stack of where that occurred. So we have a link as button method post hyphen slash

register, which is our post to register button right here. So whenever our AdonisJS server renders out this template and sends it back, this is just coming through as an empty string

rather than the button that is being shown here on the client. So we can click on that and the behavior still works, but it isn't there on the actual server side rendering.

And we can confirm that by jumping into our network tab. We go ahead and hide the console away there, scroll up to our document right here where we see our register page and taking a look at the response.

And you'll see that we get register and a click me button. Our post to register and our habit account links are not there at all. So back to our hydration mismatch.

If we scroll up, we will see that we have another one for our actual anchor from our href pointing to our login page. So we're gonna get a warning per mismatch that we have,

and then we'll get a single error stating that there were mismatches. So if you have your warnings hidden, you will still see an error in your console

stating that there were mismatches with the hydration. And then if you add your warnings in, you'll start to see what each individual mismatch was along with what it rendered on the server,

what it rendered on the client and the call stack with which net rendering occurred. Thankfully, this particular hydration mismatch has a super simple fix. We made a change inside of our app.ts file

to register this link component globally for our view application. Well, all that we need to do is register that link component globally

on our server rendered application as well. So I'm gonna go ahead and copy that link import, jump over to our ssr.ts and paste it in up there at the top.

Oh, actually we already have an import from InertiaJS, so I'm gonna go ahead and just add it to that link right there. And then if we jump down into our setup method, here is where we are creating our view application

on the server render. So after our use, adding in our plugin, we can, just like we did on the client, add in our component call with the name of link

and tell it to use the component link for that. We can give all that a save. And with that applied, let's jump back into our browser, give everything a refresh. And you can now see that we don't have any hydration

mismatch warnings or errors happening. Our server render now matches our client, meaning everything's a-okay. Furthermore, if we jump into our network,

take a look at our register response. There's our link once again, and there's our button to post to slash register.