The Building Blocks

Narrated

Your trip planner works. It has a frontend and a backend, all handled by Next.js. The pages display what the user sees. The API routes handle the AI and the secrets. Clean separation. Everything works.

Now try this. Ask Claude Code to add a loading spinner while the trip is generating. Then ask it to show an error message if something goes wrong. Then ask it to add a “save this trip” button at the bottom of each itinerary.

Each change works on its own. But notice what’s happening to your main page file. Every new feature touches the same file. The loading spinner needs to show and hide. The error message needs to appear and disappear. The save button needs to know which trip it belongs to. Claude Code is juggling all of these in one big page, and every time you add something, it has to be careful not to break something else.

This is where single-file pages start to struggle. Not because the code is bad — because the approach doesn’t scale. Imagine a page with ten features, each one showing, hiding, and updating different parts of the screen. It’s like trying to renovate every room in a house at the same time with one contractor who has to remember the state of every room at once.

There’s a better way. Instead of one big page file, you break the frontend into independent pieces. Each piece owns one part of the screen and manages itself. A search form piece. A results piece. A single trip card piece. An error message piece. Each one knows how to display itself and what to do when the user interacts with it. They don’t interfere with each other.

These pieces are called components. You’ve actually been using React this whole time — Next.js is built on React. But right now, all your React code lives in a single page file. Components are how React is meant to be used: small, focused building blocks that snap together like LEGO bricks. Instagram, Netflix, Airbnb — every major React app is built this way. And Claude Code is extremely good at organizing code into components.