Build an AI-Powered Fullstack Next.js App, v3

Creating the Entry Page

Scott Moss

Scott Moss

Superfilter AI
Build an AI-Powered Fullstack Next.js App, v3

Check out a free preview of the full Build an AI-Powered Fullstack Next.js App, v3 course

The "Creating the Entry Page" Lesson is part of the full, Build an AI-Powered Fullstack Next.js App, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Scott creates the journal entry editor page. This page will display when a user navigates to an individual entry. Issues around the revalidation of data between client and server components are also discussed in this lesson.


Transcript from the "Creating the Entry Page" Lesson

>> Let's work on the actual editor page in which we go and create that experience in which you can add journal entries to, and edit them, and things like that. If you don't know this about me, I used to have a startup that was a headless CMS. I spent so much time working on editors at this point.

I know way too much about it. I have an overflow of information on how text editors work in a browser. And we're gonna use the most simplest approach and it's gonna be great. So we're not gonna do nothing crazy. So yeah, let's get started. The first thing we need to do is create that route.

So if you go into the journal folder, make a new folder. All right, and then in this folder, we're going to call it id. Because we're navigating to /id. We don't know what the id is, so it has to be dynamic. And then in here, we can do page.tsx, Very, very, very simple.

Then we'll just say EditorPage. Or I guess you could just call it EntryPage. That might be better, EntryPage. There we go. And then inside of the props here, because it's in a dynamic route, we should have params. And then we can just return that div, and then I'll just do

I do because I've named the folder id. If I named the folder anything else, it would be params.anythingelse. Cool, so now when I click on this, it actually goes somewhere. Which is really cool. All right, let me make another entry right quick. Okay, yep. And then when I click on New Entry, it goes to the new entry as well, so we're good there.

And there's the problem, we should have three entries now. I just made a new one, but it's only showing two, right? I'm gonna make a fourth one. There's a fourth one. If I go back, it's still only showing two. I'm gonna make a fifth one. It's still only showing two.

If I refresh this, boom, they show up, right? So that's the problem that I was trying to show. We'll fix this problem later. But for now, that's because, again, fetching data on the server, updating data, creating data on the client, they know nothing about each other. They're not connected systems.

By default, you have to connect them. So this page that's fetching from the server doesn't know that the database in which it pulls from got changed. So it doesn't know that it needs to do anything. The quick way you could get around this is just change the layout.

Well, no, you couldn't do it here. No, there is no quick way. [LAUGH] I was gonna say you could just change this into a template. But I forgot we're getting the data in the page, not the layout. So there really isn't a quick way other than, I guess, changing.

No, there isn't a quick way. It's gonna be the way that I figured out is the quick way, but there is no other quick way. [LAUGH] You can't just change this to a client and be like, done, right? You can't just be like, got it, we're good now.

No, because then all this breaks. This breaks, this breaks. You can forget about doing that. None of this is gonna work. It's just dead now, so it's not that simple, yeah.
>> A hypothetical way to do that, though, would be to pull out those pieces that we wanted to be rendered on the client into separate components, give them to use client directive, and then import them to this page component.

Is that correct? So that everything here would still be server rendered, but then there would be those little kind of islands of client rendered and client hydrated.
>> Yeah, so if you go down that approach, what you would have to do is, basically, all of this would be server.

All of this would be server. And then this part would be client. So you go to make another component called entries list or something like that. That's a client component. And then it fetches data on the client, like in a use effect. I would just do a use effect and get all the data, and then you can render that.

That would work, but it won't look like this when you load it. It won't look like that. You will see this thing pop up, this thing pop up, and then these things will pop up afterwards. And then the slower your connection, the more dramatic that would be. But then you can show loading states if you wanted to.

So like I said, there's never a right answer. There's only trade-offs in software, that's really it. It's just like, well, what trade-off do you wanna deal with? Nothing's perfect, which one can you deal with? Which one do you want to deal with? That's basically it. I go for the one that's the easiest to do.

And then I don't change anything, so [LAUGH] that's basically it. I don't move on from that.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now