Chapter 9The real project: React and Next.js

Chapter 9 · Step 14

The real project: React and Next.js

4 min · 844 words

Up to here we've been working in plain HTML. For a prototype, that's perfect. For a professional site, it isn't enough. A professional site needs a library called React, made by Facebook, and a framework called Next.js. Let me explain both words, because you're going to hear them a lot.

React is a library for building websites. It's the global standard: the most widely used. And because it's the most used, the community and other software companies build a huge number of add-ons that we get to use.

A framework is like a toolbox that's already been built so we don't have to do everything from scratch. Next.js is the framework we use: it's the standard for professional websites, and among other things it gives us security. React is the library; Next.js is the framework that works with that library and lets us build much sturdier, more sophisticated sites.

From the HTML prototype to the Next.js project Prototype (HTML)every page repeats the nav bar, the footer,the cardsHomeProductCheckoutProject (Next.js + React)components: Lego bricks reused on every pageNav barFooterCardHomeProductCheckout+ 404 page, content/ folder, animations
Figure 16. In HTML each page draws its own nav bar. In Next.js the bar is a component: built once.

There's another reason to leave HTML behind: components. In HTML, if the top bar is the same on every page, every file has to draw it again. In React, that bar is a component: you build it once and use it on every page. Edit it in one place and it changes everywhere. It's like building with Lego bricks. And the project ends up with a much healthier architecture.

Step 14: a new, empty folder

When you approve the prototype, the skill records that it's ready and asks you for a new GitHub repository. That's where it'll create the final project.

Over to GitHub Desktop: new repository, in the same Documents/GitHub folder. I like naming it after the technology we're going to use, then the site's name: nextjs-juszzz. Private, like the other one.

The skill asks for the repository's URL, but the folder is really all it needs: you hand it the empty folder you just created, and that's where it'll set up the project. The URL is only in case you want to work with something else.

And it starts. It takes the prototype and moves it to Next.js, with several good practices the skill recommends. It builds the components. It creates the editable content folder (you'll see what that's for). It creates a 404 page, the one people see when they go to an address that doesn't exist on the site.

In the video, at this point, I ran out of disk space and had to free some up to carry on. I mention it because it happens: ChatGPT leaves temporary files around, and if you're also recording your screen, the disk fills up. Always keep a bit of free space.

Localhost and compiling

Once the project is built, ChatGPT runs it on localhost. Localhost is your own computer acting as a web server: you see the site in your browser, but only you can see it. It opens it, screenshots every resolution, and audits every page like it's been doing. Notice you're doing nothing at this point: it's changing the pages, creating them, auditing them.

That's why it sometimes burns through so many tokens: all the steps it takes to make sure it comes out right. But it's necessary. Not checking that everything works at every resolution is something that bites you later, when you're close to the final result. Right now, while it's building from scratch, it's much easier for ChatGPT to notice and get it right in one go. Of course, you have to ask for all of that, and you have to use skills designed for it.

And there's one more thing it does, and it's one of the great things about this skill: it compiles. Compiling means exporting the site to the version that gets uploaded: a folder called build with the site ready to go. There are often errors in the code that you don't see when you run the site locally, because the framework lets you keep working even with them there. When you compile, they surface. Having the skill check at every step that it compiles with no errors is what gives us confidence that the step really was done properly and is finished.

Localhost, build and publish LocalhostYour computer as theserver. Only you cansee it.BuildThe site gets exported.Errors you didn't seelocally show up.AuditScreenshots on desktop,tablet and phone.PublishGitHub → Vercel.Everyone can see it.errors? fix them and build again
Figure 17. On localhost only you see it. The build surfaces hidden errors. Only then does it get published.

When it says "compiles with no errors, looks right on phone, tablet and desktop," you look at it in the browser. You'll see exactly the same thing as the prototype, but now they're React pages, not HTML. That's the base we need to start adding animations and changing things.

I thought it looked good, true to the prototype, and told it to continue.

Now, finally: the magic.