When I built my first React app, I thought everything should live in one file—like a digital hoarder refusing to let go. It worked… until it didn’t. Debugging was a nightmare, I couldn't find anything, and every little tweak risked breaking something completely unrelated. That’s when I learned the power of structuring your React app thoughtfully from day one. And no, it doesn’t have to be over-engineered like some enterprise beast. In this lesson, we’ll break down how to sketch a clean component tree, actually respect separation of concerns (without going full academic), and design a folder structure that doesn’t make you want to cry at 2am.

Let’s Sketch Our Component Tree (Because Whiteboards Still Matter)

Before you write a single line of code, sketch the thing.

I resisted this for years. “I don’t need to draw boxes. I’m a developer!” But after redoing my component structure for the third time in one week, I gave in. And wow—game changer.

Here’s the deal: your component tree is the blueprint of your UI. It tells you what’s a parent, what’s reusable, and where data needs to flow.

Think of it like this:

* App

Header MainContent

* ProductList

ProductCard Footer

Simple, readable, and—best of all—predictable. You know where things go and why they live there.

Tools like Excalidraw are fantastic for sketching these out. Don’t overthink it. Boxes and arrows are enough.

Separation of Concerns in the Real World (aka Don't Mix Your Laundry)

Here’s where I messed up early on: I’d have components rendering UI and fetching data and formatting dates and managing state. All in one chaotic mess. It was like trying to cook, clean, and DJ a party at the same time—something’s gonna burn.

In React, separation of concerns means:

UI components should just render stuff. Data-fetching should live in its own place (custom hooks, for example). * Utility functions? Keep them out of the JSX.

This makes components easier to test, read, and reuse. You don’t want your ProductCard to know how to hit an API. It just needs to display a product, period.

Pro tip: create a /hooks, /utils, and /components folder. Keeps things from turning into a giant junk drawer.

Folder Structure That Won’t Come Back to Haunt You

I’ve tried dozens of React folder structures. Some were minimal. Some were so "scalable" they needed a roadmap just to find the files.

Here’s what works for most React projects (especially if you're building with Vite or CRA):

          src/
  components/
    Header/
      Header.jsx
      Header.css
    ProductCard/
      ProductCard.jsx
      ProductCard.css
  pages/
    Home.jsx
    Product.jsx
  hooks/
    useProducts.js
  utils/
    formatPrice.js
  App.jsx
  index.js
        

Each component gets its own folder if it has styles or tests. Keeps things modular. Avoid deeply nested folder structures—this isn’t a backend monolith. Keep it shallow, easy to scan, and consistent.

One more thing: name files with .jsx if they return JSX. It’s a nice clarity boost when reading the codebase.

Once you’ve sketched your app and set up the structure, it’s time to get dynamic. In the next lesson, we’ll dive into **what state is, and why developers won’t shut up about it**. Trust me—it’s the beating heart of every React app.