Vite Build Tools

youhoc

Pages
- Home
- Modern App Guidelines
- Linux
  Day 1: Linux Distributions & Navigation
  Day 2: User Management
  Day 3: File Permission & Ownership
  Day 4: Package Management
  Day 5: Services Management
- Javascript
  JS The Weird Part
  Execution Context
  Types & Operators
  Objects & Functions
  Error Handling & Strict Mode
  Typescript, ES6, Tra
  Modern JS
  JS in the Browser
  Data Storage JSON
  Modern JS
  Advanced Objects & Methods
  Webpack & Babel
  Async
  jQuery
  In-depth Analysis of jQuery
  React-ready JS
  Arrow Function
  Template Literals
  Logical AND, OR, Ternary, Nullish Operators
  Destructuring & Rest Operator
  Array Method
  Immutability and Spread Operator
  Promises, Async/Await, Callback
- PHP
  gruntJS
  composer
  MySQL
- Docker
  Container Basics
  Container Networking
  Container Image
  Container Volume & Persistent Data
  Dockerfile
  Docker Compose
  Docker Registry
- Node.js
  1. Installing & Exploring
  2. Core Modules
  3. Get User Input
  File System & Input Arguments
  5. Express Web Server
  6. Deploy to Heroku & Github
  Authentication
  7. Databases
  8. Rest API
- ReactJS
  React from Andrew
  Summary from Next
  1. Basics
  2. React Components
  3. Webpack
  4. Styling with SCSS
  5. React Router
  6. React Hook
  Modern React From The Beginning
  Intro to JSX
  Vite Build Tools
  Basic Component Creation
  Component State
  Props & Component Composition
  useState with Inputs & Form Submission
  useEffect, useRef & Local Storage
  Async / Await and Http Request in React
  React Router: Declarative Mode
  ContextAPI
  React Router: Framework Mode
  File-routing & HTML Layouts
  Server-side Data Query
  Links & Navigation
  Loaders
- Typescript
  Type User vs UserProp
- Payload CMS

youhoc

...

Vite Build Tools

Vite is a build tool that aims to provide a faster and more efficient development experience for modern web projects.

To create a React app with Vite, you need to have Node.js installed on your machine.

Create a React App with Vite

Minimal file structure of a Vite project.

You will see in the `src/main.jsx` file that we are importing the `App` component from `App.jsx` and rendering it to the root element in the `index.html` file just like I showed you in the previous lessons. It's just now everything is organized in a more scalable way.

It also uses the `<StrictMode>` component from React. This is a development feature that helps you find common problems in your React app. It will only show warnings in the console, so it's safe to use in production.

Review the package.json file

What Happens When You Run npm run dev

Vite starts a local development server on http://localhost:5173.

Instead of bundling everything, it serves JavaScript files on demand as the browser requests them.

Fast hot module replacement (HMR) allows updates to instantly appear in the browser without a full reload.

What Happens When You Run npm run build

Vite bundles all your React components into optimized JavaScript and CSS files.

It minifies JavaScript and removes unused code (tree shaking).

Generates a dist/ folder containing all the necessary static files for deployment. These are the files that you would upload to a web server to deploy your app. You do not upload the source code to the server.

You can run the npm run preview command to preview the production build locally.

Vite with Tailwind CSS

Version 4 of Tailwind CSS was released, so to get up and running is a bit different than we used to do but it is really simple.

Thư viện Tailwind UI Kit

⁠

https://www.greatfrontend.com/blog/10-best-free-tailwind-based-component-libraries-and-ui-kits⁠

⁠

shadcn/ui:

https://ui.shadcn.com/⁠

⁠

Daisy UI:

https://daisyui.com/⁠

⁠

Next UI:

https://nextui.org/⁠

⁠

Tremor:

https://www.tremor.so/⁠

⁠

Hyper UI:

https://www.hyperui.dev/⁠

⁠

Preline:

https://preline.co/⁠

⁠

Pines UI:

https://devdojo.com/pines⁠

⁠

Sailboat UI:

https://sailboatui.com/⁠

⁠

Park UI:

https://park-ui.com/⁠

⁠

Aceternity:

https://ui.aceternity.com/⁠

⁠

Env Var in Vite

Environment variables are special values stored outside your code that let you configure your app without hardcoding sensitive or environment-specific info.

Biến môi trường thay đổi theo môi trường

local khác

production khác

dùng để chạy các trạng thái dữ liệu khác nhau, không bị ghi chồng chéo

Biến môi trường không nên lưu trong code (và KHÔNG NÊN commit lên Github)

tìm cách lưu trực tiếp trong từng môi trường, ví dụ, Cloudflare Bindings, Github Secrects...

ignore các file .env trong code

Phân biệt biến môi trường được sử dụng ở đâu

biến dùng ở client-side và server-side

biến dùng khi BUILD, khi RUN

Biến môi trường nên được giữ bí mật

Defining Environment Variables with .env Files

Vite projects support dot.env files for defining environment variables.

You typically place these files at the project root (where your vite.config.js or index.html lives).

Vite will automatically load these files on startup without any extra packages.

The naming of the files can target all environments or specific modes (development, production, etc.). Common file names include:

.env – Loaded in all cases (base default variables) .env.local – Loaded in all cases, but intended to be local-only (not checked into git) .env.development , .env.production (i.e. .env.[mode]) – Loaded only for that specific mode (when running in that mode) .env.development.local , .env.production.local (i.e. .env.[mode].local) – Mode-specific and local-only (not in git)

When you run the dev server or build, Vite determines the “mode” (development by default for vite dev , and production by default for vite build ).

It will load .env and .env.local first, then the mode-specific files.

Mode-specific env files override the generic ones if they define the same variable.

For example, if both .env and .env.production define VITE_API_URL, the value from .env.production will be used in production builds.

The VITE_ Prefix Requirement

One important rule in Vite is that only variables prefixed with VITE_ are exposed to your client-side code.

This is a safety feature to prevent accidentally leaking sensitive keys. Vite will load all the variables from your .env files, but any variable that does not start with VITE_ will be omitted from the app’s front-end code

For example, suppose your .env contains:

In this case, VITE_SOME_KEY will be available in your React app, but DB_PASSWORD will not be exposed.

If you try to access it, it will be `undefined` in the browser.

This behavior is by design – you might keep truly sensitive secrets (like database passwords) in .env files for backend or build processes, but you wouldn’t want them accidentally shipped to the client.

Why the prefix? By enforcing a prefix, Vite makes you explicitly mark which env vars should be visible to front-end code.

Accessing Environment Variables in React Components

In a Vite + React app (client-side), you access env variables through the special import.meta.env object.

This object includes all your VITE_* variables (as well as some built-in variables like mode flags). For example, using the variables from above:

If you have worked with environment variables in Node on the backend, you are probably used to using process.env to access them.

Vite does not use process.env in the browser, as it is not available there. Instead, you use import.meta.env to access your environment variables in the front-end code.

Security Considerations

As I mentioned, when using VITE* prefix, Vite will expose those variables to the client-side code. This means that anyone can see them in the browser’s developer tools.

Therefore, you should never put sensitive information (like API keys or passwords) in your .env files if they are prefixed with `VITE*`.

Always keep sensitive information on the server side and use environment variables only for non-sensitive configuration values.

There are certain keys that you can make public.

For example, Stripe has a public key and a secret key. The public key can be exposed to the client-side code, but the secret key should never be exposed.

Google Maps and other Google APIs are safe as long as you implement the restrictions from the dashboard. The Firebase client SDK keys can be public as well.

Anything that says "secret" or "private" should never be exposed to the client-side code. For this, you have a few options:

Create a backend server that acts as a proxy for your API requests. This way, you can keep your API keys secret on the server side and only expose the necessary endpoints to the client.

Serverless functions are another option. You can create serverless functions that act as a proxy for your API requests. You make a request to the serverless function, and it makes the request to the API with the secret key. You could use something like AWS Lambda, Netlify Functions, or Vercel Functions to create these serverless functions.

Cloudflare workers are another option. You can create a Cloudflare worker that acts as a proxy for your API requests. You make a request to the Cloudflare worker, and it makes the request to the API with the secret key.

Secrets Managers are another option. You can use a secrets manager to store your API keys and other sensitive information.