Introduction to Next.js Routing and Navigation Q&A

Transcript from the "Routing and Navigation Q&A" Lesson

[00:00:00]
>> The reason why you need that as in this case, or can you leave that out?
>> The reason you need the as in this case is because, without this, how would Next.js know what the value of this id is? Without you telling Next.js that, hey, the actual value of this id parameter is actually node.id, it would not know, so you do have to put the as there.

[00:00:33] And, as is only gonna be for dynamic routes. If you don't have a dynamic route, like you're just navigating to a route that's hard coded, like /settings, you don't need as, because you know the path of it, you can just say go here. But, if your name of your route has a parameter in it, then you need to let Next.js know how to resolve that parameter and do this.

[00:00:57] So, but this just tells Next.js, okay, what component, what page are we loading, cuz it's doing some prefetching stuff, that's the other thing. Next.js is doing a lot of prefetching stuff in the background that you get for free with a link component. And then the as one is mostly for the browser like, okay, here's where I work, here's where I want you to go, and here's where I kinda want you to prefetch, that type of thing.

[00:01:17] So, yes, you do need to ask for parameters in the URL.
>> Do all routes have to be declared from the root of the Pages folder?
>> So, all-
>> Like when you were doing a link there?
>> So when you're doing link, I see what you're saying, like this relativity here?

[00:01:36]
>> Yeah, does it always have to be relative to the root of the Pages folder? Or, if I don't do the /folder, derive it from my current folder?
>> I don't think it's relative, I think it's relative to the Pages folder, yes.
>> Okay.
>> Yeah.
>> Are there any SEO considerations when using link?

[00:01:54]
>> Are there any SEO considerations? No, I mean, no more considerations than you would have if you were using any other client-side router. Cuz, like I said before, it only proxies the HTML5 pushState experience, which depending on where you're trying to get this site indexed, if you're getting indexed by Google, Google does index JavaScript now, it does crawl JavaScript.

[00:02:21] So, you shouldn't have a problem there if you didn't have them before. But, things like Twitter and Facebook, I don't think they crawl JavaScript yet, so yeah, you might have issues there. And again, this is for client-side routing. But, also remember that, by default Next.js is going to pre-render every single page by default.

[00:02:43] So, when it comes to being index and crawl, all of this is from the crawlers experience, this is gonna be HTML anyway. This is for after rehydration happens. So, your page gets turned into a stream on the server and gets sent back to the browser's HTML. It gets sent to a crawler's HTML, and then it rehydrates on the front end, which is basically, you can think of it as like, this JavaScript comes down, it looks at the DOM to figure out where it needs to mount.

[00:03:12] It matches, its DOM with what the server sent down to see if they're the same, and then it does some stuff with JavaScript to inject some props. That's rehydration, all that's happening. But that's for your users, that's for the browser. As far as the crawler, they're gonna see the HTML, unless you opt out of that.

[00:03:30]
>> It seems that they're saying that if you take that as a block, and just put it into a trap and remove as it still works, is there any problem of doing it that way?
>> No, I don't think there's any problem with doing it that way. I'm not aware of any side effects there might be.

[00:03:50] The only guy I could think of, and I can't confirm this, because I just haven't looked into it. Is that you might be opting out of prefetching if you do that with the link component. I can look into that later if someone else wants to look into it, but that might be the case, cuz I think they need to notice in order to do some type of optimized prefetching, but again, I could be wrong.

[00:04:10] But this is the recommended approach, so I'm guessing they recommend it for a reason. And I'm pretty sure it's for prefetching.
>> The routing happens on the client-side but, all of the routes have already been pre-rendered, right? Because of the server-side render.
>> Yeah, the navigating using the link component happens on the client-side, but the actual routes were defined at build time.