useEffect - Side Effects, Data Fetching & Async State
Browser DevTools - The Network Tab
You've built something. Now let's put it on the internet.
This chapter covers what happens when you deploy a React application: what the build step does, how Vercel turns your code into a live URL, how environment variables work locally and in production, and where to go if something breaks.
When you run npm run dev, Vite starts a development server. It compiles files on demand, shows detailed error messages, and reloads the browser when you save. That's convenient for development — but it's not how you serve an application to real users.
Before deploying, your application has to be built: transformed from source code into an optimised set of files the browser can load efficiently. Run it yourself to see what it does:
npm run build
During the build, Vite:
When the build finishes, Vite writes the output to a dist/ folder. That folder is what gets deployed — it's plain HTML, CSS, and JavaScript that any static hosting platform can serve.
If the build fails, read the error output carefully. It always points to a specific file and line number. TypeScript errors and invalid imports are the most common causes. The same code that worked in npm run dev can fail the build if it has a type error the dev server was ignoring.
<aside> 💡
Info
Running npm run build locally before pushing to Vercel is a good habit. It surfaces errors in seconds on your machine rather than after a deployment cycle. Think of it as a final check before you ship.
</aside>
Vercel is a hosting platform built around Git-based deployments. Connect a repository, and every push to main triggers a new deployment automatically. The entire flow from code to live URL takes about five minutes the first time.
https://www.youtube.com/watch?v=hAuyNf0Uk-w
If your project isn't already in a GitHub repository, create one and push:
git init
git add .
git commit -m "initial commit"
git remote add origin <https://github.com/your-username/your-repo.git>
git push -u origin main
Vercel runs npm install and npm run build on its servers, then serves the dist/ output. When it's done, you get a live URL: something like your-project.vercel.app.
<aside> ⌨️
Hands On
Deploy your current project to Vercel now, before adding environment variables or any other complexity. Get the basics working first: a live URL you can open in a browser.
</aside>
Once connected, Vercel watches your repository. Every push to main triggers a new production deployment. Every push to any other branch creates a preview deployment — a separate, shareable URL for that branch. This means you can share a work-in-progress with a mentor or teammate without affecting the live site.
This is the standard workflow at most companies: branches get preview URLs, main is production.
Some values don't belong in your code. An API key committed to a public GitHub repository is a security incident. Environment variables solve this: sensitive or environment-specific values live outside your codebase, injected at build time by the platform.
.env.localCreate a file called .env.local in your project root:
# .env.local
VITE_API_URL=https://api.example.com
VITE_SITE_NAME=My Portfolio
Vite loads this file automatically. Variables defined here are available in your code as import.meta.env.VARIABLE_NAME.
.env.local should be in your .gitignore — it never gets committed to your repository. Each developer on a team maintains their own .env.local with their own credentials.
VITE_ prefixIn a Vite project, only variables prefixed with VITE_ are exposed to your JavaScript code. Variables without the prefix are ignored entirely — they won't be accessible in the browser.
# .env.local
# Accessible in your code — safe for public values
VITE_API_URL=https://api.example.com
VITE_SITE_NAME=My Portfolio
# NOT accessible in your code (no VITE_ prefix)
# Don't put secrets in a Vite project at all — they'd end up in the bundle
SECRET_KEY=this-wont-work-anyway
// Accessing environment variables in a component
const apiUrl = import.meta.env.VITE_API_URL;
const siteName = import.meta.env.VITE_SITE_NAME;
<aside> ⚠️
Warning
Because Vite runs entirely in the browser, every VITE_ variable ends up in your JavaScript bundle — visible to anyone who opens DevTools. Never put API secrets, passwords, or private keys in a Vite project. If you need to keep something secret, it belongs on a server, not in a client-side application.
</aside>
Your .env.local file only exists on your machine — Vercel's servers don't have access to it. You need to add the same variables through the Vercel dashboard:
<aside> ⌨️
Hands On
Add a VITE_SITE_NAME variable to both your .env.local file and your Vercel project settings. Display it somewhere in your app: <title>{import.meta.env.VITE_SITE_NAME}</title>. Verify it works locally, then push and check the deployed version.
</aside>
When a deployment fails, Vercel shows you the build log — the same output you'd see running npm run build locally, just on their servers.
If a deployment fails, open the log and scroll to the error. Common causes:
TypeScript errors — the most frequent. A type error the dev server ignored will fail the build. Read the file path and line number, fix it locally, verify with npm run build, then push again.
Missing environment variables — if your code references import.meta.env.VITE_SOMETHING and that variable isn't set in Vercel's dashboard, it will be undefined at runtime. Check that every variable in your .env.local is also in Vercel's settings.
Import errors — a missing dependency or wrong import path. These show up clearly in the log.
The important habit: read the error, don't guess. The build log tells you exactly what went wrong and where.
Every project on Vercel has two kinds of deployments running simultaneously:
Production — the live site, built from your main branch. This is what users see at your .vercel.app URL or your custom domain.
Preview — a temporary deployment created for every other branch and every pull request. Each preview gets its own unique URL. You can share a preview URL to get feedback on a feature before it goes live.
This means you can work on a new section of your portfolio on a branch, push it, share the preview URL with your mentor, get feedback, iterate, and only merge to main when it's ready. The live site is never touched until you're happy with the changes.
Three distinct environments:
Development — your laptop, running npm run dev. Fast feedback, detailed errors, no real users.
Preview — Vercel's servers, built from a feature branch. Real infrastructure, shareable URL, used for review before merging.
Production — Vercel's servers, built from main. What real users see.
Your .env.local is for development only. Environment variables in Vercel's dashboard apply to preview and production. This separation is why you need to add variables in two places — they're genuinely different environments running on different machines.
<aside> 🎉
Celebration
Your app is on the internet. Not running on localhost — at a real URL, on real infrastructure, that anyone can visit. Everything you push to main from here will be live within minutes.
</aside>
npm run build locally before pushing to catch errors before Vercel does.env.local — add it to .gitignore if it isn't alreadyVITE_ variable is visible in the browser bundle