Course topics

By WebNest Studio Engineering Team

React Tutorial

Building and Deploying a React Application

Development mode in React (via tools like Vite or Create React App) prioritizes fast feedback — hot reloading, unminified code, and helpful warnings — none of which belong in front of real users. Before deploying, a React app must be compiled into an optimized "production build": minified, bundled, and stripped of development-only warnings, ready to be served as static files.

Because React apps compiled this way are just HTML, CSS, and JavaScript files with no server-side logic required, they can be hosted on virtually any static file host or CDN, which is both simple and inexpensive compared to running a full application server.

Why it matters

An application on your own machine helps nobody. Deploying means building optimised static files, configuring values that differ between environments, and making sure a refresh on any page still works. Environment variables in a front end come with one rule that is a security matter: everything in the bundle is public.

Creating a Production Build

Running npm run build (the exact script name may vary slightly between Vite and Create React App, but the concept is identical) compiles the application into a small set of static files — typically an index.html plus hashed, minified JavaScript and CSS bundles — placed into a build or dist folder. This process removes development warnings, minifies code to reduce file size, and often splits code into smaller chunks so users only download what a given page needs.

Static Hosting Basics

Because the build output is just static files, it can be hosted on services like Netlify, Vercel, GitHub Pages, or any plain web server/CDN — no Node.js server is required to serve the app itself (a separate backend API, if any, is deployed independently). One routing detail matters for single-page apps: since React Router handles navigation client-side, the host must be configured to serve index.html for all unknown paths (a "rewrite" or "fallback" rule), otherwise refreshing a page like /users/42 directly will 404 on a naive static host.

Environment Variables

Configuration that differs between environments — an API base URL for staging versus production, for example — is handled through environment variables baked in at build time, not at runtime. In Vite projects these must be prefixed with VITE_ (e.g. VITE_API_URL) and accessed via import.meta.env.VITE_API_URL; in Create React App projects they must be prefixed with REACT_APP_ and accessed via process.env.REACT_APP_API_URL. Because these values are compiled directly into the static JavaScript bundle, they are visible to anyone who inspects the deployed files — secrets like private API keys must never be placed in frontend environment variables.

  • Vite: variables must start with VITE_ and are read via import.meta.env.VITE_SOMETHING.
  • Create React App: variables must start with REACT_APP_ and are read via process.env.REACT_APP_SOMETHING.
  • Never store true secrets (private keys, database credentials) in frontend env variables — they end up readable in the shipped JavaScript.

Example

Reading a build-time environment variable in a Vite-based React app

JavaScript
// .env.production (not committed with real secrets)
// VITE_API_URL=https://api.example.com

// apiClient.js
const API_BASE_URL = import.meta.env.VITE_API_URL;

export async function fetchProducts() {
  const response = await fetch(`${API_BASE_URL}/products`);
  if (!response.ok) {
    throw new Error('Failed to load products');
  }
  return response.json();
}

// Build and preview the production bundle locally:
// npm run build
// npm run preview
Output
After "npm run build", a dist/ folder is created containing minified index.html, JS, and CSS files with VITE_API_URL already compiled in as "https://api.example.com". "npm run preview" serves that production build locally so you can verify it before deploying it to static hosting.

Common Mistakes

  • Deploying the "dev" server output instead of running a production build first — development mode is far larger and slower, and not meant for real users.
  • Forgetting to configure a single-page-app fallback rule on the static host, causing direct navigation or refreshes on client-side routes (like /users/42) to 404.
  • Putting a secret API key in a VITE_ or REACT_APP_ environment variable, not realizing it gets bundled into publicly readable JavaScript.
  • Expecting an environment variable change to take effect without rebuilding — these values are baked in at build time, not read at runtime.

Exercise

Do this in a Vite + React project. Create a file named .env in the project root that defines the API address https://api.example.com in a variable the browser code is allowed to read. Read it in src/App.jsx and show it in a paragraph. Then write the two commands that create the production build and preview it locally.

Expected result: the page shows "API: https://api.example.com", and the build command creates a dist folder of static files.

JavaScript · starter code
# .env
# TODO: the API address, in a variable exposed to the client

// src/App.jsx
export default function App() {
  // TODO: read the variable
  return <p>API: </p>;
}

# terminal
# TODO: build for production
# TODO: preview the build
Show hints
  • Vite exposes only variables whose names start with VITE_.
  • They are read from import.meta.env, for example import.meta.env.VITE_API_URL.
Show solution
JavaScript · solution
# .env
VITE_API_URL=https://api.example.com

// src/App.jsx
export default function App() {
  const apiUrl = import.meta.env.VITE_API_URL;
  return <p>API: {apiUrl}</p>;
}

# terminal
npm run build
npm run preview

Quick quiz

1. What does npm run build produce in a Vite project?

  • A. A running server
  • B. A Docker image
  • C. Optimised static files in the dist folder
  • D. A database
Show answer

C. The files can be served by any static host.

2. Is it safe to put a secret API key in a VITE_ variable?

  • A. No; the value is embedded in the JavaScript that every visitor downloads
  • B. Yes, it is encrypted
  • C. Yes, if the file is called .env
  • D. Only in production
Show answer

A. Secrets must stay on a server, which makes the call on the browser's behalf.

3. Why does refreshing /about on a deployed single-page application sometimes give a 404?

  • A. The build failed
  • B. The route is misspelled
  • C. React Router does not support refresh
  • D. The server looks for a file at that path; it must be configured to return index.html for all routes
Show answer

D. This is called a rewrite, or history fallback, rule.

Interview questions

How do you deploy a React application?

Show answer

Run the production build, which compiles, bundles and minifies the code into static HTML, CSS and JavaScript files. Upload that folder to a static host such as Vercel, Netlify or an object store behind a CDN, usually through a pipeline that builds on every push. Configure the host to serve index.html for unknown paths so that client-side routes work on refresh, and set the environment variables for that environment.

How do environment variables work in a front-end application?

Show answer

They are read at build time and written into the bundle as plain values, so they are fixed when the application is built and are visible to anyone who downloads it. In Vite only variables prefixed with VITE_ are exposed, through import.meta.env. They are suitable for public configuration, such as an API address or a public key, and never for secrets, which belong on a server.

Key Points to Remember

  • npm run build produces an optimized, minified static bundle ready for production hosting.
  • React apps can be served from any static host or CDN; single-page apps need a fallback rule routing all paths to index.html.
  • Environment variables must use the framework's required prefix (VITE_ or REACT_APP_) and are baked into the bundle at build time.
  • Never place real secrets in frontend environment variables, since the built JavaScript is publicly inspectable.

Practice in the playground

Write and run your own code for this topic, or start from the exercise or an example. Shows a live preview of plain HTML, CSS and JavaScript. JSX needs a React project on your computer. Your code for each topic is kept in this browser.

Run the examples

Change an input, predict the result, then compare it with the output. Explain why the result changes.

These examples need a project environment on your computer, so they can be copied but not run here. Codelab runs Python, FastAPI backends with SQLite, plain Java 17 and HTML/CSS/JavaScript.

WebNest Studio

Written by

WebNest Studio Engineering Team

Practical lessons from developers working with Java, Python, React, databases and production systems.

Led by Vansh Duggal, Founder, WebNest Studio · Full-stack & software engineering