This one's just more of a lecture on how next Js does
rendering because I think it's important.
I would say it's probably a little advanced and
I probably didn't need to put this here.
But it confused me until I understood this so
I made a really good choice is just put this in here and talk about it.
But basically Next Js has like two different rendering modes statically or
dynamically, right?
So static routes are like components that render ahead of time.
Like at build time when I run the build command I'm deploying it.
And it gets rendered there and the results are cached.
So they're static.
And that's kind of what I talked about with a blog post,
the content this page is never going to change or
maybe the landing page the content is pages never going to change.
It doesn't rely on some dynamic data that needs to be updated all the time.
It's only going to change when we rebuild it.
So that's the static route.
Whereas a dynamic route might be something with a parameter in it that's a user ID
where it's like, well, this is the user's feed.
This is literally going to change every time someone goes to it.
So I don't want to cache this.
I don't want this to be like rendered when I deploy it, and
then cache it, and send it back every time.
If that was the case, and this was Instagram, we'd all see the same feed.
It has to be dynamic, we have to go to the server and make an API call,
get new data every single time someone goes to this URL.
So next Js figures this out for you without you having to do it.
You just have to give it hints.
And some of the ways you can give it hints is basically by using some of
the functions that it provides.
So if you've never heard of fetch, by default fetch is built into Next.js and
they've like on the server side and client side and they've like hijacked it to try
to figure out what it is that you're doing with with your with that route,
with that component.
So if you're using fetch, it knows that like you're probably doing something
dynamic here because you're you're grabbing data when the page is rendering.
So therefore.
Maybe we shouldn't cache this page by default, right?
Or it gives you the ability to interfere with that cache and
try to change the rules of that cache, like when it revalidates,
how often to revalidate it, different things like that.
It can get pretty crazy.
And then you also have The ability, like if you use anything dynamic
like a cookies function that they have or headers function that they have.
This also tells next js that, you're doing something dynamic,
you're using these functions, and you're grabbing a cookie from somewhere, or
you're looking at the header somewhere.
That means you're doing some logic that's dynamic,
so we're not going to statically render this page.
Because you're using one of these functions so.
And that just happens for you for free.
And I didn't know that when I started using xjs 13.
And I kept having these issues where I kept getting back cache pages.
And it was I just did not understand and sometimes I wouldn't.
And it's because of this,
if you use any of these functions that they provide for you.
It's automatically going to opt you into Dynamic routing, and
if you don't use any of them.
So that means by default every single page is statically rendered, and
it's going to be cached.
But they do give you tools to dive into that cache.
I don't want to get into them because I could spend a week talking about caching.
It's incredibly difficult to go into it There's tons of documentation on it,
but yeah, by default everything is going
to be statically rendered unless you use one of these functions.
Yeah, so Next.js is just like,
I think a lot of in the past it's always been, build an app.
Do whatever you want.
And then you get to the end of it and you're like, all right,
now let's figure out performance.
And you start like taking away things, you start optimizing things,
you start minimizing things.
Next Js is like well, what if we just turn on performance day one out of the box.
Everything default is gonna be performing and
then you gotta opt out of the performance.
So, that's the approach that they're going for.
It seems to be working for them.
I don't think it works in all cases, but I think it works for
them because they have such a strong convention around how you build your App.
Like as far as like what file names are, and what folder names are I think you have
to have that convention in order to create something that's performant.
Otherwise, if people could just make whatever they want, whatever they want,
how would they get performance by default?
It would be a mess.
So it works for them, but that's that's their philosophy.
It's just like,
how do we make sure everything that everyone is shipping is fast by default?
So that's what they're doing.
Cool.
Any questions?