How your browser loads, parses, and renders a webpage


## Why this post?

The other day, I was reading [this discussion](https://github.com/react-hook-form/react-hook-form/discussions/8233) about handling async, default form values in React Hook Form and it occurred to me that 1) present day, there are a lot of conflicting opinions and "best practices" when dealing with forms in React, and 2) for a long time I struggled with forms and it was about time to organize my thoughts.

This post is an _exploration_ of "best practices" when dealing with React forms. By no means does it cover everything nor am I an expert in form design. These are just a collection of my notes after years of struggling to build stable and predictable forms in React.

## Prerequisites

This is an intermediate level post. You should:

- Understand the basics of React hooks and functional components
- Understand [the lifecycle of a React functional component](<[https://www.zachgollwitzer.com/posts/how-browsers-load-websites](https://www.zachgollwitzer.com/posts/lifecycle-of-react-component)>)
- Understand async data fetching in React, and preferably, a basic understanding of [what React Query does](https://react-query-v3.tanstack.com/overview) since I'll be using that as an example at some point in the post.

## Controlled vs. Uncontrolled forms

When dealing with forms in React, it is **critical** to understand "controlled" vs. "uncontrolled" forms and inputs. Here's how I like to remember it:

- Uncontrolled - let the browser keep track of form values
- Controlled - let React keep track of form values as **state**

Here is an **uncontrolled** form:

```tsx
function UncontrolledForm() {
  return (
    <form action="/some-endpoint" method="post">
      <input name="exampleInput" defaultValue={2} min={2} required />
      <button>Submit</button>
    </form>
  );
}
```

When you click "Submit", the browser will wrangle all the form values, validate that the input is 1) filled out and 2) greater or equal to a value of `2`, and submit to your `action` endpoint via `POST` request.

But in many cases, you want more **control** over the form than this.

Here is the same form as above, but as a **controlled** form:

```tsx
function parseForm(form: HTMLFormElement) {
  // parse, validate, and return form data
}

function ControlledForm() {
  const [form, setForm] = useState({ exampleInput: 2 });

  function handleSubmit(event) {
    event.preventDefault();

    const data = parseForm(event.target);

    fetch('/some-endpoint', { method: 'post', data });
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        name="exampleInput"
        value={form.exampleInput}
        onChange={(e) =>
          setForm((prev) => ({ ...prev, exampleInput: e.target.value }))
        }
        min={2}
        required
      />
      <button>Submit</button>
    </form>
  );
}
```

There are a couple of very important implications to a controlled form in React.

1. `defaultValue` does nothing when input is controlled
2. `value` and `onChange` must **both** be implemented and stored in a React state variable
3. You should never set `value` to `null` or `undefined`. This [will confuse React](https://beta.reactjs.org/reference/react-dom/components/input#im-getting-an-error-a-component-is-changing-an-uncontrolled-input-to-be-controlled) into thinking you are using an uncontrolled input.

### defaultValue doesn't do anything with Controlled forms

If you read my post on [React component lifecycle](https://www.zachgollwitzer.com/posts/lifecycle-of-react-component), you know that on the _first render_ of any component, the state variable is initialized:

```tsx
const [form, setForm] = useState({ exampleInput: 2 });
```

In our example from above, on the **first render**, the value of `form` will always be `{ exampleInput: 2 }`, and therefore, our input element will have a `value` of `2`. In other words, even if we _tried_ to set `defaultValue`, it would never apply because `value` will always be populated according to `useState` default value.

### Input value should not be set to undefined in Controlled form

Do not do this:

```tsx
<input name="exampleInput" value={undefined} />
```

Or equivalent in an actual form example:

```tsx
const [exampleInput, setExampleInput] = useState();
// const [exampleInput, setExampleInput] = useState(undefined); <--- or this!

<input name="exampleInput" value={exampleInput} onChange={setExampleInput} />;
```

If you do this, React will _think_ this is an **uncontrolled** input and initialize it as such. Once you start typing into the input, you'll get this error:

```txt
Warning: A component is changing an uncontrolled input to be controlled. This is likely caused by the value changing from undefined to a defined value, which should not happen. Decide between using a controlled or uncontrolled input element for the lifetime of the component.
```

The `value` prop of an input [must remain a string](https://beta.reactjs.org/reference/react-dom/components/input#im-getting-an-error-a-component-is-changing-an-uncontrolled-input-to-be-controlled) through its lifetime for React to properly handle it as a controlled input. Furthermore, as the error suggests, a form input cannot change from a controlled => uncontrolled or vice-versa during its lifetime.

### Input value should not be set to null in Controlled form

Do not do this:

```tsx
const [exampleInput, setExampleInput] = useState(null);

<input name="exampleInput" value={exampleInput} onChange={setExampleInput} />;
```

For the same reasons explained in the previous section, this will confuse React into thinking this is an uncontrolled input, when really, it is controlled. If you do this, you will get this error:

```txt
Warning: `value` prop on `input` should not be null. Consider using an empty string to clear the component or `undefined` for uncontrolled components.
```

### How to initialize Controlled form with values from async, external API

It is a very common pattern to initialize a form with some data stored in an external data store.

1. Load data on first page load
2. Render form with async data as "default value"
3. User changes data within the form

#### Strategy 1: Loading state, then render

Here's a relatively stable pattern for achieving this. It involves a "Data Fetcher" component that is responsible for displaying a loading state until the data arrives and then rendering the form when the data is available. Once the form renders, no additional data requests will happen and the form value will be updated by the user.

Here's a simple form:

```tsx
function FormComponent({ defaultValue }: { defaultValue: string }) {
  const [title, setTitle] = useState(defaultValue);

  return (
    <form>
      <input
        name="title"
        value={title}
        onChange={(e) => setTitle(e.target.value)}
      />
    </form>
  );
}
```

And then here's the "Data Fetcher":

```tsx
type Todo = {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
};

function DataFetchingComponent() {
  const [todo, setTodo] = useState<Todo>();

  useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/todos/1')
      .then((response) => response.json())
      .then((json) => setTodo(json));
  }, []);

  if (!todo) {
    return <p>Loading...</p>;
  }

  return <FormComponent defaultValue={todo.title} />;
}
```

As you can see, we never have to handle "nullish" default values because we're not rendering the form until we _know_ data is available.

#### Strategy 2: Reset form when data arrives

If the first strategy doesn't meet your needs, you might have to deal with loading the data in the same component that the form is rendered. When using this strategy, our "no undefined or null form value" rule applies.

In the code below, we have a PROBLEM. Can you spot it?

```tsx
function FormWithAsyncInitialValues() {
  const [title, setTitle] = useState<string>();

  useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/todos/1')
      .then((response) => response.json())
      .then((json: Todo) => setTitle(json.title));
  }, []);

  return (
    <form>
      <input
        name="title"
        value={title}
        onChange={(e) => setTitle(e.target.value)}
      />
    </form>
  );
}
```

If you use this code, you will get the dreaded `A component is changing an uncontrolled input to be controlled`. Why?

Because on the first render, our async data fetching call hasn't run yet, which means `title` is equal to `undefined`. This means that we're actually setting our input's `value=undefined` on the first render. After the network request succeeds, `title` will be a `string` value and now our input `value` will be defined.

Since our first value was `undefined`, React initialized this form as **uncontrolled** but we later updated it to be **controlled**, which is not allowed.

To fix this, all we need to do is initialize our `title` as an empty string. So we'll go from this:

```tsx
// BAD!!!
const [title, setTitle] = useState<string>();
```

To this:

```tsx
// GOOD :)
const [title, setTitle] = useState<string>('');
```

## Do I need a form library?

In a day where there's a library for just about everything, it might come as a shock that regular 'ole HTML + vanilla React is a pretty powerful combination when it comes to building forms. Here's a perfectly valid way to build a form:

```tsx
import type { FormEvent } from 'react';

export function MyForm() {
  function handleSubmit(e: FormEvent<HTMLFormElement>) {
    e.preventDefault();

    const form = new FormData(e.target as HTMLFormElement);
    const parsedData = Object.fromEntries(form.entries());

    // Do something with the form data
    const { jobOccupation } = parsedData;
    console.log(jobOccupation);
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        name="jobOccupation"
        defaultValue="Software Engineer (default value)"
      />
      <button>Submit</button>
    </form>
  );
}
```

You can see we're using **uncontrolled** inputs on this form and then once the form submits, we're intercepting the submit event, parsing through the data, and doing something with it.

Need to turn this into a **controlled** form so you can use form values elsewhere in the component? You can do that without a library too:

```tsx
export function MyForm() {
  const [form, setForm] = useState({
    jobOccupation: 'Software Engineer (default value)',
    age: '50', // form stores as string, converts to number on submit
  });

  function handleSubmit(e: FormEvent<HTMLFormElement>) {
    e.preventDefault();

    const form = new FormData(e.target as HTMLFormElement);
    const parsedData = Object.fromEntries(form.entries());

    // Do something with the form data
    const { jobOccupation, age } = parsedData;
    console.log(jobOccupation); // string
    console.log(+age); // number
  }

  return (
    <div>
      {/* One benefit of a controlled form is the ability to display form values outside of the form */}
      <p>
        User is a {form.age} year old {form.jobOccupation}
      </p>
      <form onSubmit={handleSubmit}>
        <input
          name="jobOccupation"
          value={form.jobOccupation}
          onChange={(e) =>
            setForm((prev) => ({ ...prev, jobOccupation: e.target.value }))
          }
        />

        <input
          name="age"
          value={form.age}
          onChange={(e) =>
            setForm((prev) => ({ ...prev, age: e.target.value }))
          }
        />
      </form>
    </div>
  );
}
```

Above, I showed an uncontrolled and controlled form implemented with basic React state. So why would you need a library?

As your form grows in size and complexity (especially dynamically constructed forms), handling the form's global "state" in a single state variable becomes difficult. Furthermore, you'll run into challenges of...

- Validating inputs as they change and displaying an error message close to the affected input
- Optimizing performance of the form and avoiding too many re-renders (in our example above, any change to any input re-renders the entire form component)
- Integrating custom input components from external libraries like Material UI
- Handling "touched" and "dirty" form states (i.e. if the user has already typed into an input, we might want to handle that differently than if they haven't touched it)
- If you're using TypeScript, having a fully "typesafe" form becomes difficult as the form grows

For any semi-complex form, you will run into these problems.

### When and Why I use React Hook Form

Ideally, we'd have the best of both worlds. For simple forms, we don't need the overhead of a form library, and for complex ones, we could bring in a library.

This is the reason I use `react-hook-form` for all but the simplest of forms. React Hook Form (RHF) uses a simple React hook called `useForm` that allows for native form HTML while also providing the ability to control inputs, validate inputs, and parse form data on submission.

In my opinion, this is the way to go in almost every scenario. With that said, let's jump into some more complex topics!

## Using React Hook Form

Now that we have a solid understanding of how React itself handles forms and the difference between **controlled** and **uncontrolled**, React Hook Form (RHF) will make a lot more sense.

Under the hood, RHF embraces **uncontrolled** inputs which allows you to leverage all the native browser form APIs while also getting the benefit of all the library has to offer.

In the case you _need_ to control an input (e.g. you're integrating a custom input component), RHF also provides native support for that via the `Controller` component.

The best part is that we can _mix_ controlled and uncontrolled inputs in the same form without any change in behavior!

This post is not meant to be _documentation_, but rather a catalogue of patterns that I've used with RHF. The following sections are some of those patterns.

### React Query + React Hook Form + Zod Validation

React Query + RHF + Zod (and TypeScript) is my current go-to setup for building forms in React. Below is a basic form example that wires all of these libraries up to work together. While the code is self-explanatory, there are a few things I want to highlight.

- **Validation** - there are three levels of validation that can happen with forms, and while you probably don't _need_ all three, they each provide a slightly different assurance.
  - **Input level validation** - This level of validation is great for validating an input and immediately showing a descriptive error message to the user to notify them that the form is invalid.
  - **Form submission validation** - This level of validation (using Zod or another validation library) becomes more and more useful as your forms grow in size. More specifically, it becomes useful when your form has _conditional_ fields that you are registering/unregistering based on certain conditions because handling this sort of logic at the field level is complicated and usually not worth the effort. It is also useful if you want to add some more complex field validation that is _not_ shown to the user.
  - **Backend validation** - This is not shown in the example, but the API you submit your data to will often perform some validation either at the request level or database level. If you have already validated the data on the frontend, this might seem useless, but backend validation will provide you with the assurance that someone hasn't intentionally modified the `POST` request sent from the form.
- **Async default values** - In the example, you can see that we're not rendering the form until we have our default values populated. While RHF does allow you to pass an _async_ function to `defaultValues`, I find it more stable to load the data and _then_ render the form to avoid the [complexity described here](https://github.com/react-hook-form/react-hook-form/issues/2492#issue-673907790).

```tsx
import './styles.css';
import {
  QueryClient,
  QueryClientProvider,
  useQuery,
  useMutation,
} from '@tanstack/react-query';
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';

const queryClient = new QueryClient();

type Post = {
  userId: number;
  id: number;
  title: string;
  body: string;
};

// Zod schema for form values
const FormSchema = z.object({
  title: z.string(),
  body: z.string(),
});

// { title: string; body: string; }
type FormData = z.infer<typeof FormSchema>;

type FormProps = {
  defaultValues: FormData;
  onSubmit(data: FormData): void;
  isSubmitting: boolean;
};

function FormComponent({ onSubmit, defaultValues, isSubmitting }: FormProps) {
  const { register, handleSubmit } = useForm<FormData>({
    defaultValues,
    resolver: zodResolver(FormSchema),
  });

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register('title', { required: true })} />
      <textarea {...register('body')} />
      <button
        disabled={isSubmitting} // Prevents double-submit
      >
        Submit
      </button>
    </form>
  );
}

function DataFetcher() {
  const query = useQuery<Post>(['posts'], () => {
    return fetch('https://jsonplaceholder.typicode.com/posts/1')
      .then((response) => response.json())
      .then((json) => json);
  });

  const mutation = useMutation((data: FormData) => {
    return fetch('https://jsonplaceholder.typicode.com/posts', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(data),
    });
  });

  if (query.isError) {
    return <p>Error, could not load form.</p>;
  }

  if (query.isLoading) {
    return <p>Loading...</p>;
  }

  // Since we have checked loading & error states, we know data is valid
  const { title, body } = query.data;

  return (
    <FormComponent
      defaultValues={{ title, body }}
      onSubmit={async (data) => {
        await mutation.mutateAsync(data);
        alert('Form submitted successfully!');
      }}
      isSubmitting={mutation.isLoading}
    />
  );
}

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <div className="App">
        <DataFetcher />
      </div>
    </QueryClientProvider>
  );
}
```


React Forms Best Practices

The Secret Life of a React Component


Recently, I was working on a beginner-focused video about building a basic React app, and it occurred to me that there aren't many resources online that explain how to create a _vanilla_ (loose term here) TypeScript + React18 application without all the boilerplate that CRA (`create-react-app`) adds to the mix.

So here's a brief guide explaining my solution for React 18.x and TypeScript 4.x+.

## Source Code

You can find a working example of the [code explained below in my repo here.](https://github.com/zachgoll/boilerplate/tree/main/vanilla-react18-typescript-webpack)

## Required packages

For this setup, you'll need all of the following packages:

```
# React
yarn add react react-dom

# Types
yarn add -D @types/node @types/react @types/react-dom @types/copy-webpack-plugin

# Build tools
yarn add -D typescript ts-loader webpack webpack-cli copy-webpack-plugin style-loader css-loader ts-node webpack-dev-server
```

As a brief overview, here's what each dependency is primarily for:

- `react`, `react-dom` - our React app!
- `@types/*` and `typescript` - TypeScript type definitions and compiler
- `webpack`, `webpack-cli`, `webpack-dev-server` - for running webpack builds via command line (see scripts in `package.json`) and serving in local dev
- `ts-loader`, `style-loader`, `css-loader` - the loaders that Webpack will use to properly bundle our TypeScript and CSS files.
- `copy-webpack-plugin` - this copies the `/public` directory to `/dist` so that `/dist` has everything needed to run an app!
- `ts-node` - mainly used to actually run Webpack (since we defined the Webpack config as a `.ts` file)

## Directory Structure

This is obviously a matter of preference, but here's the directory structure we'll be using:

```
dist/  # Build outputs (not in source control)
public/
  index.html
  globals.css
src/
  components/
    Footer.tsx
    Footer.css
  entrypoint.tsx
  App.tsx
```

## Public Assets

First up, let's look at `public/index.html`

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="globals.css" />
    <title>Document</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="bundle.js"></script>
  </body>
  <html></html>
</html>
```

As simple as it gets! Our `bundle.js` will be the bundled React app, which will render inside the `id="root"` element, and inherit all the styles from `globals.css` (along with per-component styles, which will override globals).

Next, our `public/globals.css` file, which just has two styles:

```css
p {
  color: green;
}

a {
  color: blue;
}
```

## React App

Our app is simple. It has some text and a footer component.

Here is `src/App.tsx`:

```tsx
import Footer from './components/Footer';

export default function App() {
  return (
    <main>
      <p>App</p>
      <Footer />
    </main>
  );
}
```

`src/components/Footer.tsx` looks like this:

```tsx
import './Footer.css';

export default function Footer() {
  return (
    <footer>
      <a href="#">A Footer Link</a>
    </footer>
  );
}
```

And finally, here's the footer CSS. I have intentionally added a conflicting style to demonstrate CSS specificity between CSS modules and `globals.css`. Links in the footer will be red instead of blue (defined in `globals.css`).

```css
/* Footer.css */

a {
  color: red;
}
```

### Rendering the app root

By default, these components won't show up in the DOM. We need to initialize React by creating a "root" and rendering our app into it. To do this, I have created a `src/entrypoint.tsx` with the following contents. Please note, this is different syntax than you're probably used to seeing as React v18.x introduced the `createRoot` method vs. the old `ReactDOM.render` method.

```tsx
import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';
import App from './App';

const rootElement = document.getElementById('root');

// New as of React v18.x
const root = createRoot(rootElement!);

root.render(
  <StrictMode>
    <App />
  </StrictMode>
);
```

And that's it! That's the entirety of our application, and is intentionally as simple and useless as possible to better demonstrate the real purpose of this tutorial, which is setting up a minimal group of _build tools_ required to get this thing working!

## Setting up TypeScript and Webpack

By default, if we open up `index.html` in the browser, it's not going to find the `bundle.js` we added because that doesn't exist yet. This `bundle.js` will be created as an _output_ of the TypeScript + Webpack build script (`yarn build`).

Of course, you could install the `react-scripts` package (used by CRA), or even simpler, just use `create-react-app`, but that's not our goal here. Our goal is to define the simplest setup possible, and to do that, we'll be configuring everything from scratch. We could of course use something else besides Webpack to do this, but Webpack is what I'm most familiar with and I would assume most devs are too.

### Configuring TypeScript with React 18

For starters, we need a `tsconfig.json`. What does this do for us?

1. Allows our editor (I'm using VSCode) to use intellisense for type-checking
2. Allows the TypeScript compiler (`tsc`) to know _how_ to compile typescript files (and JSX-flavored files).
3. Used by Webpack to perform step #2

This will vary depending on your needs, but here's a relatively standard starter:

```json
{
  "compilerOptions": {
    "jsx": "react-jsx" /* IMPORTANT! - this allows our JSX to be transpiled correctly */,
    "target": "es6" /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */,
    "esModuleInterop": true /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables 'allowSyntheticDefaultImports' for type compatibility. */,
    "allowSyntheticDefaultImports": true /* Need for Webpack config file */,
    "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,
    "strict": true /* Enable all strict type-checking options. */,
    "skipLibCheck": true /* Skip type checking all .d.ts files. */,
    "outDir": "dist",
    "moduleResolution": "node"
  },
  "include": ["**/*.ts", "**/*.tsx"]
}
```

Believe it or not, this is all we need to start compiling our files with TypeScript. If you've followed the steps above, you should be able to run:

```
yarn tsc
```

This will run the TypeScript compiler against all files we specified in the `include` array of our config and write them as `ES6` (see `target` and `module` options) to the `dist/` directory (see `outDir` option).

But... This isn't so helpful. We still don't have a `bundle.js` file that we can include in `index.html`, and `index.html` doesn't get copied to `dist/` yet. It's time to bring in Webpack!

### Configuring Webpack with React18 + TypeScript

We now need a file called `webpack.config.ts` in the root of our project.

```ts
import path from 'path';
import { Configuration } from 'webpack';
import CopyWebpackPlugin from 'copy-webpack-plugin';

const config: Configuration = {
  mode:
    (process.env.NODE_ENV as 'production' | 'development' | undefined) ??
    'development',
  entry: './src/entrypoint.tsx',
  module: {
    rules: [
      {
        test: /.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  plugins: [
    new CopyWebpackPlugin({
      patterns: [{ from: 'public' }],
    }),
  ],
};

export default config;
```

This has quite a bit going on in it, so let's take it a section at a time.

First, let's look at the input and output config:

```ts
{
  entry: './src/entrypoint.tsx',
  output: {
    filename: "bundle.js",
    path: path.resolve(__dirname, "dist")
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
}
```

The `entry` determines what file Webpack will build `bundle.js` from. The `output` then tells webpack to combine everything and save it to `dist/bundle.js`. Finally, `resolve` tells webpack [_how_ to resolve modules](https://www.zachgollwitzer.com/posts/scripts-commonjs-umd-amd-es6-modules).

Next up, we have the loaders:

```ts
{
  module: {
    rules: [
      {
        test: /.tsx?$/,
        use: "ts-loader",
        exclude: /node_modules/,
      },
      {
        test: /\.css$/,
        use: ["style-loader", "css-loader"],
      },
    ],
  },
}
```

This specifies which loaders to use for files matched to the `test` property regex. It is important to understand that `ts-loader` will read our `tsconfig.json` file to know how to type-check our TS files and transpile our JSX to JavaScript that the browser can understand.

And finally, we have the `CopyWebpackPlugin`:

```ts
{
  plugins: [
    new CopyWebpackPlugin({
      patterns: [{ from: "public" }],
    }),
  ],
}
```

For larger projects, you generally won't be using this plugin. Instead, you might use the [HTMLWebpackPlugin](https://webpack.js.org/plugins/html-webpack-plugin/).

Since this project is so small, I'm using this to copy the entire `public/` directory (which has `index.html` and `globals.css`) to the `dist/` directory, which is where Webpack is going to save the `bundle.js`. In `index.html`, you'll see this line:

```html
<script src="bundle.js"></script>
```

Based on this, `bundle.js` needs to be in the same directory as `index.html`. Furthermore, it is a good practice to keep _all_ build outputs in one spot. In effect, after the build, our `dist/` directory will look like this:

```
dist/
  index.html
  globals.css
  bundle.js
```

### Building and serving the React app

At this point, everything is configured. In our `webpack.config.ts`, notice that we are using `NODE_ENV` to specify the output environment, so let's create a production build like so:

```
NODE_ENV=production yarn build
```

This will create the `dist/` directory with everything needed to serve the app.

Open `dist/index.html` in your browser and you should see the app running!

## Live Reloads with Webpack Dev Server

While our app is working, we definitely want the ability to make changes to the source without having to run `yarn build` every time. To do this, we can utilize [Webpack dev server](https://webpack.js.org/configuration/dev-server/), which is now incredibly easy to set up.

All we need to do is run our script `yarn dev`, which will then run:

```
webpack serve
```

There is one very important detail to consider here. Webpack dev server rebuilds and stores the build output _in memory_, so you will not see the `dist/` directory changing each time you make a change to your application. Additionally, do you recall this line in `index.html`?

```html
<script src="bundle.js"></script>
```

How does the dev server know where to find `index.html`? If you look at `stdout` for the dev server cli, you'll see this line:

```
<i> [webpack-dev-server] Content not from webpack is served from ......
```

By default, Webpack dev server will look in the `public/` folder for static content, which means _by default_, it is picking up our `index.html` and `globals.css` files and combining them with `bundle.js`, just like our build script does via the `CopyWebpackPlugin`.

If you have `index.html` in a different directory, you can configure the dev server in `webpack.config.ts` to load public assets from another location.

```ts
// webpack.config.ts

devServer: {
  static: {
    directory: path.resolve(__dirname, 'your-custom-directory');
  }
}
```

## Wrapping up

And that's it! A vanilla-(ish) React 18 app with TypeScript.

While I would generally recommend using automated tooling like `create-react-app` or `create-next-app`, hopefully this setup has been instructive and helps you understand what is going on behind the scenes with many JavaScript build toolchains.


Zach Gollwitzer

About me

Recent posts