React Project Structure, Best Practices, Deployment and What to Learn Next

You now know the building blocks of React. This final lesson joins them together. You will learn how to organise a real project, the habits that keep code clean, how to deploy your app so others can use it, and what to learn next. Think of it as the guide to leave the course and start building.

Project structure

There is no single correct structure. A good one is easy to understand and easy to change. Here is a simple layout that works well up to a medium-sized app:

src/
  main.jsx
  App.jsx
  api.js                 // fetch helper and API functions
  components/            // shared pieces: Button, Modal, Card
  pages/                 // one file per page: Home, Products, Login
  hooks/                 // custom hooks: useDebounce, useFetch
  context/               // providers: AuthContext, ThemeContext
  utils/                 // plain helper functions: formatDate, validate
  assets/                // images and fonts
  styles/                // global CSS

When the app grows, many teams switch from grouping by type (all components together) to grouping by feature, where each feature has its own folder with its own components, hooks and tests:

src/
  features/
    cart/
      CartPage.jsx
      CartItem.jsx
      useCart.js
      cart.test.jsx
    auth/
      LoginPage.jsx
      AuthContext.jsx
  components/            // only truly shared UI

The feature layout keeps related files together, so changing the cart means working in one folder. Start simple, and reorganise when it begins to hurt.

Naming and file habits

• Components: PascalCase, in a file with the same name (ProductCard.jsx).
• Hooks: start with use (useDebounce.js).
• Functions and variables: camelCase. Constants such as a fixed list: UPPER_CASE if you like.
• One component per file, and keep files short. If a file grows past a few hundred lines, split it.
• Name things for what they are, not how they look: PrimaryButton is better than BlueButton.

Best practices

1. Keep components small and focused. One job each. If a component does too much, split it.
2. Keep state as low as possible, and lift it only when needed. Calculate what you can instead of storing it.
3. Never change state directly. Make copies.
4. Use real HTML elements (button, a, nav, label) for accessibility and less code.
5. Handle loading, empty and error states on every screen that loads data.
6. Use stable keys in lists. Never random keys.
7. Clean up effects (timers, listeners, requests).
8. Do not optimise early. Measure first, then fix real problems.
9. Write a few tests for your most important flows and rules.
10. Use ESLint and Prettier so the whole team writes code in the same way.

Environment variables

Settings like the address of your API change between your computer and the live site. Put them in .env files. In Vite, variables must start with VITE_ to be available in the browser:

# .env
VITE_API_URL=http://localhost:5000/api

const API_URL = import.meta.env.VITE_API_URL;

Security basics for React apps

• React escapes values in JSX, which protects you from most script injection. But never use dangerouslySetInnerHTML with content you did not clean. If you must show HTML from users, clean it with a library such as DOMPurify.
• Check links built from user input: a javascript: link in an href can run code. Allow only http and https addresses.
• Store login tokens carefully. Cookies with the HttpOnly flag, set by the server, are safer than localStorage, which any script on the page can read.
• Keep your packages updated and run npm audit now and then.
• The server must check every permission and validate every input. Hiding a button in React protects nothing.

Check before you ship

• Run npm run build and npm run preview, and test the real build.
• Run Lighthouse and fix the biggest problems for performance, accessibility and SEO.
• Test on a real phone, or at a narrow width of about 390 pixels, and check that nothing scrolls sideways.
• Try the app with the keyboard only.
• Look in the console for errors and warnings.
• Give each page a unique title and description.

Deploy your app

npm run build makes a folder called dist with plain files (HTML, JavaScript and CSS). Any place that can serve files can host it. Your main options:

• Static hosting platforms (several free and paid ones exist). You connect your Git repository, and they build and publish your site on every push. This is the easiest way for beginners. Compare their current free limits on their own sites, as these change.
• Your own server with nginx or similar, serving the dist folder. More work, and more control.
• Together with your API: let your Node server serve the dist folder, so one server runs everything.

Two things to remember for any host:

• Single page app fallback: because React Router draws pages in the browser, a visit to /products/3 must return index.html. Turn on the “rewrite all to index.html” setting on your host.
• HTTPS: most platforms give it free. Always use it.

# nginx example: serve the dist folder with a fallback to index.html
server {
  listen 80;
  server_name example.com;
  root /var/www/my-app/dist;
  index index.html;

  location / {
    try_files $uri /index.html;
  }

  # Files with a hash in the name can be cached for a long time
  location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
  }
}

SEO and React

A plain React app sends an almost empty HTML file, and builds the page in the browser. Search engines can often run JavaScript, but it is slower and less reliable, and sharing links on social media shows poor previews. For pages that must rank well, like articles, product pages and landing pages, consider:

• A framework with server rendering, such as Next.js, which sends complete HTML.
• Pre-rendering your key pages at build time.
• At the very least, a unique title and description per page, real links (a or Link), a sitemap, and fast loading.

For private dashboards behind a login, plain React is fine, because search engines do not need to see them.

Your next steps

You have learned the core of React. Here is a good order to keep growing:

1. Build projects. A to-do app, a movie search, a weather app, a notes app with login, an expense tracker. Finish them, deploy them and put them in your portfolio. This matters more than any course.
2. Next.js, a framework built on React. It adds file-based pages, server rendering, data loading and more. Most of what you learned here applies directly.
3. TypeScript in every new project. It is common in jobs.
4. A backend: Node.js and Express with a database such as MongoDB or PostgreSQL, so you can build full applications. Our MERN stack course does this step by step.
5. Testing and continuous integration to keep a growing project healthy.
6. More advanced topics: Server Components, animations (with CSS or a library such as Framer Motion), real-time features with WebSockets, and mobile apps with React Native.

How to keep learning well

• Read the official docs at react.dev. They are clear and have many small examples.
• Read other people's code in open source projects, and try fixing small issues.
• Build the same project twice: once simple, once with better structure, and compare.
• Explain what you learn to someone else, or write about it. Teaching is the best test.
• Do not chase every new library. Learn the ideas first, because the ideas stay the same when the tools change.

A final project idea

Build a job tracker with the tools of this course: pages with React Router, a list with filters kept in the URL, a form with validation, data loaded with TanStack Query, shared login state in context, a loading and error screen for every request, a dark mode, tests for the form and the list, and a deploy to a live address. Add one feature of your own, write a short README with screenshots, and show it. You will have used almost everything from these thirty lessons in a single real app.

Common mistakes to avoid

• Putting secrets in React code or VITE_ variables.
• Skipping the host's fallback to index.html, so reloads give 404 errors.
• Over-engineering: adding Redux, TypeScript and ten libraries to a tiny app.
• Never finishing projects. Small and finished beats big and unfinished.
• Trusting the front end for security.

Your task

1. Take one of your projects and reorganise it into the folder layout above.
2. Run a production build, preview it and run Lighthouse. Fix the top three issues.
3. Deploy it to a free static host and open the live link on your phone.
4. Write down your next three projects and the first step of each.

How to check it worked

• The live site loads over HTTPS and a reload on a deep page still works.
• The console has no errors or secret keys in the code.
• You have a short list of projects to build next.

Summary

• Organise by type at first, then by feature as the app grows. Keep components small and named clearly.
• Follow the habits: low state, no direct changes, real HTML, loading and error states, clean effects, a few good tests.
• Never put secrets in React code. The server must check permissions. Build with npm run build and deploy the dist folder with a fallback to index.html.
• Keep building real projects, and learn Next.js, TypeScript and a backend next.