Can you have multiple pages in a folder?
>> You cannot have multiple pages in a folder because URLs are unique.
So you have to think about the segment.
So if you think about it like this,
let's say I wanted to put another page inside of docs.
I'll put another page in here.
One, how would Next.js know which one to render?
And then two, what would you expect from a user's perspective, when you go to a URL?
I guess you would expect to see the same thing.
Going to a URL and seeing a completely different page is probably confusing.
Imagine going to a blog post on a URL, and then it shows one blog post.
And you go to the exact same URL again, then it shows a different blog post.
That would be very confusing.
So no, if you want a different page, you need a new segment.
And to make a new segment, you need a new folder, so can't do multiple pages.
>> Do you need to use the default export?
>> Yes, every page has to have a default export of the component in
which it's rendering.
So if I got rid of, let's just say I said export, like that.
And then I tried to go to /todos.
Yeah, it breaks, right?
Next.js does it because if you don't do a default export,
that means you're doing a named export.
And if you're doing a named export,
how would Next.js know what the name of your component is?
It could be anything.
I mean, I guess it could figure it out, but that's a lot of work.
So, it's better for tooling.
It just allows the framework to make really good assumptions about things,
versus having to figure things out.
>> So you no longer can use file names for routing, so for instance,
home.dashboard.settings or something like that?
>> Yeah, you can't use file names for routing.
So in the pages, in the older version of Next.js 12 and
below, you wouldn't have a page.tsx.
In fact, the name of the route would be the name of the file.
So in the case of docs, I might have docs, and
then this section dot tsx, this other section dot tsx.
And each one of those files would be the name of the route at
which it gets rendered there.
So no, you can't do that anymore.
Every folder has to have a page component in it, and it has to be that name.
And the file names themselves do not determine the segments in a route.
Only folders determine the segments in a route, and
that's only if they don't have parentheses around them.
So it's definitely way different than 12, right?
12 would literally, Next.js 12 would literally have multiple pages in one
folder, each page being its own file name which corresponds to a different route.
And only when you wanna make a new segment, would you make a new folder.
But in this case, everything has to have a folder and
you have to have a page.tsx in it.
And you can only have one in each folder.
Cool, all right, so let's keep it moving.
So we talked about that.
There's also some really cool things in here, like I said, layouts, loading.
Or I mentioned layout.
There's these things called loading and error files.
I'm not gonna talk about them too much.
I'm just putting them in here for context.
We're gonna to get into them in more detail a little later,
when we do data fetching.
Cuz right now, they wouldn't make any sense,
unless I taught you what data fetching was.
But I just wanted to put them in there just because someone might ask questions.
But the other thing to think about, or
one thing I want to show you, is that you didn't know it, but
this whole time you've been writing server components.
I know, shocker, right?
These aren't regular React components.
These are components that actually get executed, and ran, and
rendered on the server, and have no JavaScript equivalent on the front end.
So anything that we just wrote does not have JavaScript associated with it on
the front end.
There's no JavaScript to download and it completely ran on the server.
Which means anything you can do in Node.js,
you can do in any one of these files right now.
I don't know, is there a specific Node.js thing, let me think.
I think I could just log maybe the process or something.
Let's see, console.log process.
Wait, I got some stuff on there.
[LAUGH] I don't want to log my process.
Let me log the process.argv, let's see.
So yeah, and then now I will go to this page, which is this Todos.
Let me change this to Todos, so it's not confusing.
There we go.
And let's go there, go to Todos.
It still rendered, so it didn't break.
And then you can see it logged the process.argv,
which is only accessible in Node.js.
You can't log, there's no process in the browser.
So this is proof that it's running on the server.
It's executing on the server, it's not happening in the browser.
And if it was happening in a browser like an SSR component,
which renders on the server first and then goes to the browser, well, as soon as
the browser would have saw this, it would have freaked out and it would have died.
Cuz this doesn't exist in the browser.
And it didn't, it clearly rendered here.
There's no errors here about process doesn't exist, or
arg does not exist on undefined.
So yeah, that's completely running on a server for free by default.
It's a little crazy.
So the reason they did that is to make it easier for
you to opt into server components.
Versus, the other way around is where you would manually have to,
this is a server component.
This is a server component.
Then it's like, well, let's just make everything a server component by default,
so people get it for free.
And then if they want to opt out of it,
there's something they can use to opt out of it.
And I'll show what you that is in a little bit.
Cool, any questions on that?
Yeah, yes, question, Mark?
>> So an SSR is a bunch of concatenation to create HTML?
>> Okay, server-side rendering is basically taking React.
So you have to separate React from React DOM.
React, the framework itself,
is a framework that allows you to be expressive in how you create UIs.
And then React DOM is like taking that and translating it to the DOM in the browser.
But if you just took React itself,
it can actually run in many different environments.
It can run in a React server, it can run in React Native.
It can run in many different environments.
So all server side rendering is doing is taking React,
the framework that allows you to create UIs, and building a React server
environment that translates it to run inside of a Node.js environment.
And basically, instead of spitting out something that goes to the DOM,
like DOM nodes, it spits out a string.
It spits out HTML string.
That HTML string gets sent to the browser as an HTML document, and
then the browser shows it.
So that's what server side rendering is.
It's like I'm gonna take this React, I'm gonna convert it to an HTML string.
And I'm gonna give it to the browser.
That's basically it, that's server side rendering.
Server side component is a little different.
It's also doing server side rendering, but
its logic is also being executed on the server.
I don't know how to best describe that, it's like [LAUGH].
And then also with server side rendering, although I am sending HTML for
that component to the browser, there is a client component that gets downloaded
that is an exact replica of that server side component,
that eventually takes over the server side HTML.
So that way it's interactive, right?
So it's like, all right, here's the HTML for the initial render.
Okay, now wait for the JavaScript to download, wait for
the JavaScript to download.
Okay, cool, here's the equivalent client version of that component.
Get rid of the server one and put the client one in now, so
people can actually use this thing.
That doesn't happen with the server component.
A server component is purely HTML, everything's executed on the server.
There is no client side thing taking over.
As far as the browser is concerned, it's just HTML.
It doesn't know that this is React, and
there's no JavaScript waiting to hydrate it.
So that's the difference.