>> Scott Moss: We were talking about styling and
why you should just use Tailwind.
And let me get to the notes.
So, yeah, just use Tailwind.
So now what we wanna do is, let's just go in and
actually fill out these marketing pages.
We have quite a few.
So we have the landing page, which you already made, but it does nothing.
And we have the layout for the marketing page, which you made and
also does nothing.
But as you can see for the layout in this case, it's a great place to do navigation.
So we'll have a header in here where you have links to the other pages.
I didn't ask for you to make those other routes.
And you still don't have to make them now.
But if you want to, here's all the code for those other routes as well.
This is just to show you how to use the link component to link to other pages.
There's nothing special in any of this code outside of just regular React and
just styling.
So feel free just to copy and paste these in, that's what I'm going to do.
And then we'll demonstrate what it means to have a static page.
How you can tell you have a static page with Next.js, because what we're
gonna get into after this is gonna be dynamic and it's way different.
So I want you to have a good foundation of static pages.
And what does that mean when it comes to performance,
caching, building, stuff like that.
So let's get to it.
So I'm going to take my index page,
put that in here for marketing page.
Just get that out of here, go.
One cool thing, though,
that is worth a mention is this components, this Timestamp one.
So who here has never seen 'use client'?
Interesting, everybody has seen that so far.
Okay, this has nothing to do with Next.js.
This is all React.
This is a React feature, okay?
If you don't know what this is, it's the React that you've used your whole life,
that's what this is.
This is just regular old single page application client side React.
You now have to explicitly say that with React now.
So this is called a directive.
This is the use client directive.
This one, this function is interesting because of just how static pages work.
This Timestamp is used in the footer of the page to show the incorporated year.
So you have to go change that every year.
You gotta keep that up to date if you want investors to think you're
still in business.
So [LAUGH] if you don't wanna change that every year, you're smart.
You do it with a Timestamp, with a date.
The problem is the page that you put it on is a static page and it gets cached.
This is a dynamic value that gets executed every time.
So you end up getting an error, at least in the mode that we're in.
So you have to run this on the client and put it there.
So you'll see in a minute how all this works, but, yeah,
pretty interesting thing here.
Cool, so I have my page.
Let me make sure that isn't busted.
That's right, I still have my conflict.
Let me get rid of my conflicted page right quick.
There we go, okay, cool.
So now we look like this.
Obviously, I still have my layout stuff that's rendering.
You may or may not have that, but that's why mine is doing that.
You might notice this thing down here.
What is this?
This Next.js logo, that is not from our code, I did not add that.
You did not add that.
But when you click on it, it gives you some information.
One thing it says is route static.
When you click on this, it tells you that, hey, this path that you're on,
which in this case is just index,
is marked as static since it will be pre-rendered during build time.
With static rendering, routes are rendered at build time or
in the background after data revalidation.
Static rendering is useful when a route has data that is not
personalized to the user and can be known at build time,
such as a static blog post or a product page.
So essentially, anything that doesn't change is gonna be a static site.
This is why I had to put the date in a client component because
when you compute the date is different every single time.
So I was not able to put that directly in the page without it
complaining about that.
So this is a static page.
By default, most pages are static unless you do certain things.
We'll talk about those certain things.
You've already done one of them, that's making a dynamic parameter.
And if you use that parameter inside of a page,
that automatically makes it a dynamic page, not a static page.
So there's other things you can do, like accessing cookies, explicitly saying
this is dynamic, using suspense, things that we'll be using, stuff like that.
But this is static page.
This thing gets rendered by Next.js.
You can turn it off in the Next.js config.
Just leave it here, it works.
And then, hey, go try Turbopack.
They really want you to try Turbopack, so [LAUGH] go do it.
To be fair, it is pretty good.
It is much faster, but the compatibility issues just aren't there yet.
But the team that's working on it is a very smart team.
Cool, we got that static page.
I'm gonna go get my other pages, I'm gonna put them in.
So let's grab our layouts for our marketing.
So I'll go to do that.
Go get rid of that, put this in here, cool.
So now if I go back,
I now have this navigation at the top that tries to link to other pages that
don't exist with a sign in and sign up button.
All right, keep it moving.
Let's go ahead and add, let's add a pricing page so
we can see how the link works.
So pricing is gonna be marketing/pricing page.
So let's do this, new folder, pricing, new route.
It's gonna be page.tsx.
Paste that in.
There we go.
Now if I go back, I
should be able to click on pricing, and it'll go to pricing.
So one thing I want you to take note of, I'm gonna stop my server.
Well, actually, no, it shows it right here already.
So notice it'll say things like this, Compiled, Compiled.
This happens because this is a static page and,
well, let's just talk about static or not static.
The pages themselves don't actually get rendered or
executed by Next.js until you visit them in dev mode.
So until I actually visited the price page, it didn't get compiled.
And that first compilation step takes a long time.
So you can see this took 336 milliseconds,
kind of a long time, and then it rendered it.
But it only compiled once when you stop your server and
go the first time, or if you change something in the file and
did a hot module reload and it had to recompile it.
So this could stack.
If you have dependencies in those components that are fetching data and
that data takes forever to be fetched,
you might see the compilation step take a long time, or if there's a lot going on.
So it can stack.
So sometimes in development you might have big pages, and things just take forever to
compile, and then when you execute them, they can take even longer with the data.
So just know that if you navigate to a page for the first time since you start up
your server and it took a long time, it's compiling.
Give it a second, it won't do it the second time.
And this is where Turbopack actually makes it way faster,
especially on this step right here.
And just to demonstrate that, I'm gonna stop my server.
I'm gonna start it up.
It's probably gonna compile whatever page I'm on now, which is, what, the pricing.
So I'm gonna refresh that.
You see, it just starts compiling the pricing.
It compiled the favicon.
It never compiled the homepage.
I never went there, so it never did it.
As soon as I go home, it's going to compile that one.
And there it is, it compiled that one, and boom.
>> Speaker 2: In copying over some of the stuff in terms of the pricing page,
let's say for instance,
you're just somebody who prefers to have one component per file, for instance.
Next isn't gonna care unless it's called page or layout, right?
>> Scott Moss: Yeah. They don't
>> Speaker 2: just store your components
in that same directory.
>> Scott Moss: Yep. >> Speaker 2: Yeah.
>> Scott Moss: Absolutely, unless you use one of those special names like page,
layout, template, loading, error, 404, not found.
There's a few more.
Yeah, as long as it's not that, it's not gonna care, yeah.
But yeah, I'm with you.
Look, don't judge me, this is not how I'm doing stuff in production, all right?
We ain't just throwing stuff in here all willy nilly like this.
So we're gonna have components scoped out.
But I don't want you guys copy and pasting all these files and doing all this stuff.
That's just so much work.
So we're just gonna put it in one place, but yeah, great point.
So if we go to the layout, we can look at the link component.
Here it is, it's pretty simple.
It has to have an href, and it works just like an anchor tag stuff.
It does client side routing and prefetching.
That's pretty much it.
You can turn off prefetching, you could do things like prefetch, false,
say, don't do that.
There's so many things you can do there.
But, yeah, prefetching is good by default, things like that, pretty simple.
It's pretty self-explanatory, it does what you think it does.
Cool, I'm not going to add all those other marketing pages because they're just more
of the same.
They don't actually do anything special.
So let's get to the Auth pages.
Where are they at?
There we go.
So for the sign up page, I'm gonna copy that,
go to my sign up, and put that in there.
Does it sign up?
Yeah, cool, so we have our sign up page.
And then for my sign in page, do the same thing.
>> Scott Moss: Great, and should be able to check those out.
Go on to sign up, should look like this.
You shouldn't have a form, cuz that's the next thing we're gonna make.
But you should see that if you go to sign in, pretty much the same thing.
Cool, so that's essentially static pages.
Static pages are regular pages that don't fetch data, or at least any dynamic data.
They are not personalized to the user that's looking at it.
So it's not like, depending on the user and their ID and their token,
I wanna show this thing.
That's a dynamic page.
A static page is something that's gonna be the same for everybody.
And these pages are heavily optimized.
>> Speaker 3: Can I just see your sign in page real quick?
>> Scott Moss: Sure.
>> Speaker 3: The actual page.
>> Scott Moss: The actual page, how it looks?
Yes, this is my sign in page.
Yeah, yeah, you should not see a form here.
>> Speaker 3: Yeah, I would wanna make sure you didn't have the layout either,
like the navbar.
>> Scott Moss: Got you, yeah, that's a good point.
Yeah, I don't have the navbar because the navbar layout is the marketing layout.
So the Auth won't have it.
The only layout that the Auth has is the root one cuz that's its
closest ancestor layout, which is down here somewhere here.
So yeah, it won't have that.
Now there are some other things here with static pages.
It's gonna come down to pre-rendering static pages that have dynamic values.
This is a good example for blog post pages or documentation pages.
So you have some external source.
Let's say it's a headless, yeah, a CMS or a database.
And you have 50 blog posts you need to render.
These are all static pages.
Are you gonna come in here and make 50 different blog posts?
Probably not, so you'll probably do the catch all routes cuz you're smart.
But then, how do you pre-render each one if you only have one
route made in your code that represents each one?
So Next.js has something called, cool.
So get static rams.
Basically, if you have a dynamic page like this, again,
like a blog post, and I need to go fetch all those blog posts.
And I want to pre-render a static page for
each one of those blog posts inside of that file that represents one blog post,
I would export a function called get StaticParams.
I would go get all of my blog posts from whatever source they are in.
And in this case,
I need to return an array of objects that match the dynamic parts of the URL.
So in this case, there's a slug here.
So I need to return an array that has objects that have slugs.
And then for each slug that you return here,
a route will be pre-rendered and generated for you.
So that's essentially what this is.
You can put all your blog posts in here.
Let's say you have a hundred thousand blog posts, you could do that.
Your build time's gonna be insane.
So what you can do instead is you can, I don't know,
maybe get the first 50 recent ones.
And then if anybody tries to navigate to an older one,
you do server-side generation on that.
That's called incremental regeneration.
So you would generate it.
When someone goes to visit a page,
let's say a blog post with a slug that you did not pre-render here,
Next.js will render it on the server like it's a server component.
And then now because it's static, it never has to render again.
So if somebody tries to check it two seconds after that,
they'll immediately get it without having to render like the first time,
as if you were to put it in this array.
So it basically gets rendered on demand versus you doing it
ahead of time to save time on your build time.
That was really complicated explaining, [LAUGH] but yes, that's how that works.
>> Speaker 4: Is building thousands of pages on, let's say, Vercel,
really expensive, or not that expensive?
>> Scott Moss: It's slow, it doesn't really cost.
I mean, I guess it depends on where you run it.
Vercel does build, and they're not gonna charge you extra for
build time, but it can be slow.
I've worked with companies that had hundreds of thousands of articles, and
it could take them 30, 40 minutes plus to deploy something.
I guess that's fine compared to what things normally are in bigger companies,
but it's still pretty slow.
And you're compiling things that nobody looks at.
You're compiling a blog post from ten years ago.
Who the hell's looking at that?
Nobody, so yeah, only compile the things that you need.