## React Forms 📝 Forms are where a [React](/courses/reactjs) application stops merely displaying information and starts collecting information from actual users. And users can type anything. Anything. 😌 You may ask for an email address and receive: ```text hello ``` You may ask for an age and receive: ```text -847 ``` You may ask someone to confirm their password and somehow receive something completely different in both fields. So handling forms isn't just about reading an `` value. We also need to think about **state, events, validation, errors, accessibility, submission, and user experience**. [React](/courses/reactjs) gives us two main approaches for working with form values: ```text Controlled inputs ↓ React state owns the current value Uncontrolled inputs ↓ The DOM owns the current value ``` Both are valid. The important question is: > **Who needs to know about the value while the user is editing it?** That answer usually tells you which approach fits better. --- # Controlled vs Uncontrolled Inputs Let's start with the basic difference. A controlled input looks like this: ```jsx const [name, setName] = useState("") setName(event.target.value) } /> ``` The current value comes from React state: ```jsx value={name} ``` and whenever the user types, React updates that state: ```jsx setName(event.target.value) ``` So the flow is: ```text User types ↓ onChange ↓ React state updates ↓ Component renders again ↓ Input receives latest value ``` React is in control of the value. --- # What Is an Uncontrolled Input? An uncontrolled input doesn't use React state for every change. For example: ```jsx import { useRef } from "react" function NameForm() { const nameRef = useRef(null) function handleSubmit(event) { event.preventDefault() console.log( nameRef.current.value ) } return ( ) } ``` Here, the browser itself maintains whatever the user typed. React doesn't receive every character in state. We only read the value when we need it: ```jsx nameRef.current.value ``` So: ```text User types ↓ DOM stores the value ↓ React doesn't update state ↓ Submit happens ↓ Read value from DOM ``` That's an uncontrolled input. --- # Controlled Is Not Automatically Better You'll often see beginner tutorials say: > "Always use controlled inputs." That's too strong. Controlled inputs are very useful when you need React to know the current value immediately. For example: * live validation * character counters * conditional fields * live previews * enabling/disabling buttons * filtering search results * formatting values * synchronizing multiple inputs But if you only need the value when someone submits a simple form, an uncontrolled input may be completely reasonable. So think: ```text Need value during typing? ↓ Controlled is often useful Only need value on submission? ↓ Uncontrolled may be enough ``` The goal isn't to make React control everything simply because React can. Your input has survived perfectly well in [HTML](/courses/html) for decades. It doesn't always need supervision. 😂 --- # Controlled Text Input Let's begin with the most common example. ```jsx import { useState } from "react" function NameInput() { const [name, setName] = useState("") return (

setName( event.target.value ) } placeholder="Your name" />

Hello, {name || "stranger"}!

) } ``` The input value is always whatever React has stored in: ```jsx name ``` Typing: ```text Asif ``` causes: ```jsx setName("Asif") ``` Then the component renders again and the paragraph immediately changes. That's why controlled inputs are powerful: the latest value is already available to your component. --- # Why Do We Need Both `value` and `onChange`? This confuses many beginners. Suppose you write: ```jsx ``` but don't provide an `onChange` that updates `name`. The input's displayed value is being controlled by state, but typing can't change that state. So the user types: ```text A ``` but React says: > "Interesting suggestion. Unfortunately the value is still `""`." 😌 The input appears read-only. For an editable controlled input, you typically need both: ```jsx value={name} ``` and: ```jsx onChange={...} ``` One controls what appears. The other updates the controlled value. --- # Managing Several Fields A form often has more than one input. You could create separate state variables: ```jsx const [name, setName] = useState("") const [email, setEmail] = useState("") const [password, setPassword] = useState("") ``` That's perfectly valid. For larger forms, though, you may decide to keep related values in one object: ```jsx const [form, setForm] = useState({ name: "", email: "", password: "" }) ``` Now: ```jsx form.name form.email form.password ``` contain the current values. --- # Updating One Field in a Form Object Remember that state objects should not be mutated directly. Don't do: ```jsx form.name = "Alice" ``` Instead: ```jsx setForm(previous => ({ ...previous, name: "Alice" })) ``` This preserves the other properties while replacing only `name`. The pattern becomes: ```text Copy previous form ↓ Change one field ↓ Create new object ↓ Update state ``` --- # A Generic `update()` Function Instead of repeating the same object update for every field, we can write: ```jsx function update( field, value ) { setForm(previous => ({ ...previous, [field]: value })) } ``` The interesting part is: ```jsx [field]: value ``` This is a **computed property name**. If: ```text field = "email" ``` then: ```jsx [field]: value ``` becomes: ```jsx email: value ``` If: ```text field = "name" ``` it becomes: ```jsx name: value ``` So one [function](/javascript/functions-in-javascript) can update many fields. --- # Controlled Text, Email, and Password Inputs ```jsx function BasicForm() { const [form, setForm] = useState({ name: "", email: "", password: "" }) function update( field, value ) { setForm(previous => ({ ...previous, [field]: value })) } return ( ) } ``` The input type changes browser behavior, but the React pattern stays very similar. --- # Number Inputs Are Still Slightly Sneaky Consider: ```jsx update( "age", event.target.value ) } /> ``` You might assume: ```jsx event.target.value ``` is a [JavaScript](/courses/javascript) number. It usually isn't. Input values are commonly read as strings. So if the user types: ```text 25 ``` you may receive: ```js "25" ``` not: ```js 25 ``` This often makes keeping the form state as a string convenient while the user is editing. Then convert it when needed: ```jsx const age = Number(form.age) ``` Why not immediately convert every keystroke? Because an input may temporarily contain: ```text "" ``` while the user is editing. Forms are messy little creatures. Let them breathe. 😂 --- # Controlled `

In React, a controlled textarea works just like other inputs:

```jsx
<textarea
  value={form.bio}
  onChange={event =>
    update(
      "bio",
      event.target.value
    )
  }
  placeholder="Tell us about yourself"
/>
```

The value belongs in:

```jsx
value={...}
```

rather than treating the content between the tags as your changing value.

So:

```jsx
<textarea value={form.bio} />
```

fits naturally into the same controlled-input pattern.

---

# Controlled `<select>`

A select works similarly:

```jsx
<select
  value={form.role}
  onChange={event =>
    update(
      "role",
      event.target.value
    )
  }
>
  <option value="">
    Select a role...
  </option>

<option value="developer">
    Developer
  </option>

<option value="designer">
    Designer
  </option>

<option value="manager">
    Manager
  </option>
</select>
```

The current selection comes from:

```jsx
form.role
```

If the user chooses Developer:

```text
form.role = "developer"
```

through the normal React state update.

---

# Checkboxes Are Different

Text inputs usually use:

```jsx
event.target.value
```

Checkboxes usually care about:

```jsx
event.target.checked
```

because their important state is:

```text
checked / unchecked
```

For example:

```jsx
const [agreed, setAgreed] =
  useState(false)

<input
  type="checkbox"
  checked={agreed}
  onChange={event =>
    setAgreed(
      event.target.checked
    )
  }
/>
```

If checked:

```js
true
```

If unchecked:

```js
false
```

---

# Single Checkbox Example

```jsx
<label>
  <input
    type="checkbox"
    checked={form.agreed}
    onChange={event =>
      update(
        "agreed",
        event.target.checked
      )
    }
  />

I agree to the terms
</label>
```

Notice:

```jsx
checked={form.agreed}
```

not:

```jsx
value={form.agreed}
```

That distinction matters.

---

# Checkbox Groups

Checkbox groups are useful when users can select several options.

Imagine:

```text
Skills:

☑ React
☐ Node.js
☑ CSS
```

Our state could contain:

```jsx
skills: [
  "React",
  "CSS"
]
```

Then:

```jsx
function handleSkillChange(
  skill,
  checked
) {
  setForm(previous => ({
    ...previous,

skills: checked
      ? [
          ...previous.skills,
          skill
        ]
      : previous.skills.filter(
          item =>
            item !== skill
        )
  }))
}
```

If the box becomes checked, add the value.

If it becomes unchecked, remove it.

---

# Checkbox Group Example

```jsx
const skills = [
  "React",
  "Node.js",
  "CSS"
]

{skills.map(skill => (
  <label key={skill}>
    <input
      type="checkbox"
      checked={
        form.skills.includes(
          skill
        )
      }
      onChange={event =>
        handleSkillChange(
          skill,
          event.target.checked
        )
      }
    />

{skill}
  </label>
))}
```

The array controls which checkboxes are selected.

So:

```text
form.skills
     ↓
["React", "CSS"]
```

means React and [CSS](/courses/css) appear checked.

---

# Radio Buttons

Radio buttons let the user choose **one option from a group**.

For example:

```text
Plan:

◉ Basic
○ Pro
○ Enterprise
```

We might store:

```jsx
plan: "basic"
```

Then:

```jsx
<label>
  <input
    type="radio"
    name="plan"
    value="basic"
    checked={
      form.plan === "basic"
    }
    onChange={event =>
      update(
        "plan",
        event.target.value
      )
    }
  />

Basic
</label>
```

Another option:

```jsx
<label>
  <input
    type="radio"
    name="plan"
    value="pro"
    checked={
      form.plan === "pro"
    }
    onChange={event =>
      update(
        "plan",
        event.target.value
      )
    }
  />

Pro
</label>
```

The shared:

```jsx
name="plan"
```

groups the radio buttons semantically in [HTML](/courses/html).

React state determines which one is checked.

---

# A Complete Controlled Form

Let's combine the common input types.

```jsx
import { useState } from "react"

function ProfileForm() {
  const [form, setForm] =
    useState({
      name: "",
      email: "",
      password: "",
      age: "",
      bio: "",
      role: "",
      plan: "basic",
      skills: [],
      agreed: false
    })

function update(
    field,
    value
  ) {
    setForm(previous => ({
      ...previous,
      [field]: value
    }))
  }

function handleSkillChange(
    skill,
    checked
  ) {
    setForm(previous => ({
      ...previous,

skills: checked
        ? [
            ...previous.skills,
            skill
          ]
        : previous.skills.filter(
            item =>
              item !== skill
          )
    }))
  }

return (
    <form>
      <input
        type="text"
        value={form.name}
        onChange={event =>
          update(
            "name",
            event.target.value
          )
        }
        placeholder="Name"
      />

<input
        type="email"
        value={form.email}
        onChange={event =>
          update(
            "email",
            event.target.value
          )
        }
        placeholder="Email"
      />

<input
        type="password"
        value={form.password}
        onChange={event =>
          update(
            "password",
            event.target.value
          )
        }
        placeholder="Password"
      />

<input
        type="number"
        value={form.age}
        onChange={event =>
          update(
            "age",
            event.target.value
          )
        }
        placeholder="Age"
      />

<textarea
        value={form.bio}
        onChange={event =>
          update(
            "bio",
            event.target.value
          )
        }
        placeholder="Bio"
      />

<select
        value={form.role}
        onChange={event =>
          update(
            "role",
            event.target.value
          )
        }
      >
        <option value="">
          Select role...
        </option>

<option value="developer">
          Developer
        </option>

<option value="designer">
          Designer
        </option>
      </select>

<label>
          <input
            type="radio"
            name="plan"
            value="basic"
            checked={
              form.plan ===
              "basic"
            }
            onChange={event =>
              update(
                "plan",
                event.target.value
              )
            }
          />

Basic
        </label>

<label>
          <input
            type="radio"
            name="plan"
            value="pro"
            checked={
              form.plan ===
              "pro"
            }
            onChange={event =>
              update(
                "plan",
                event.target.value
              )
            }
          />

Pro
        </label>
      </fieldset>

<fieldset>
        <legend>
          Skills
        </legend>

{[
          "React",
          "Node.js",
          "CSS"
        ].map(skill => (
          <label key={skill}>
            <input
              type="checkbox"
              checked={
                form.skills.includes(
                  skill
                )
              }
              onChange={event =>
                handleSkillChange(
                  skill,
                  event.target.checked
                )
              }
            />

{skill}
          </label>
        ))}
      </fieldset>

<label>
        <input
          type="checkbox"
          checked={form.agreed}
          onChange={event =>
            update(
              "agreed",
              event.target.checked
            )
          }
        />

I agree to the terms
      </label>
    </form>
  )
}
```

Yes, forms get long.

Welcome to the part of frontend development where one `<form>` somehow becomes 140 lines. 😭

---

# Using `name` to Create One Generic Change Handler

Instead of writing:

```jsx
update(
  "email",
  event.target.value
)
```

for every input, you can use each input's:

```jsx
name
```

attribute.

For example:

```jsx
<input
  name="email"
  value={form.email}
  onChange={handleChange}
/>
```

Then:

```jsx
function handleChange(event) {
  const {
    name,
    value
  } = event.target

setForm(previous => ({
    ...previous,
    [name]: value
  }))
}
```

If the input has:

```jsx
name="email"
```

then:

```text
name = "email"
```

and the [function](/javascript/functions-in-javascript) updates:

```jsx
form.email
```

---

# A Generic Change Handler

```jsx
function handleChange(event) {
  const {
    name,
    value,
    type,
    checked
  } = event.target

setForm(previous => ({
    ...previous,

[name]:
      type === "checkbox"
        ? checked
        : value
  }))
}
```

Now you can write:

```jsx
<input
  name="name"
  value={form.name}
  onChange={handleChange}
/>
```

and:

```jsx
<input
  name="email"
  type="email"
  value={form.email}
  onChange={handleChange}
/>
```

and:

```jsx
<input
  name="agreed"
  type="checkbox"
  checked={form.agreed}
  onChange={handleChange}
/>
```

with the same handler.

That's a very common form pattern.

---

# File Inputs Are Different 📁

File inputs deserve special attention.

Consider:

```jsx
<input type="file" />
```

The selected file comes from the browser.

You normally read it using:

```jsx
event.target.files
```

For example:

```jsx
function handleFileChange(
  event
) {
  const file =
    event.target.files[0]

console.log(file)
}
```

Then:

```jsx
<input
  type="file"
  onChange={handleFileChange}
/>
```

You don't control a file input by assigning its path through React state the same way you control normal text input values.

The browser deliberately restricts this for security reasons.

Imagine websites being able to quietly set:

```text
C:\Users\You\Documents\taxes.pdf
```

as an upload.

That would be... slightly concerning. 😭

---

# File Input Example

You may still store the selected `File` object in state:

```jsx
const [file, setFile] =
  useState(null)

function handleFileChange(
  event
) {
  const selected =
    event.target.files?.[0]

setFile(
    selected || null
  )
}
```

Then:

```jsx
<input
  type="file"
  onChange={handleFileChange}
/>

{file && (
  <p>
    Selected: {file.name}
  </p>
)}
```

The browser controls the actual file picker/input value.

React can still store information about the chosen file.

---

# Controlled Inputs Give You Immediate Access

One of the biggest advantages of controlled inputs is that your component always knows what's currently entered.

Suppose:

```jsx
const [password, setPassword] =
  useState("")
```

You can immediately calculate:

```jsx
const remaining =
  Math.max(
    0,
    8 - password.length
  )
```

Then:

```jsx
<p>
  {remaining > 0
    ? `${remaining} more characters needed`
    : "Password length looks good ✅"}
</p>
```

That's much easier because React already has the current value.

---

# Controlled Inputs Enable Conditional UI

Suppose you have:

```jsx
const [country, setCountry] =
  useState("")
```

Then:

```jsx
<select
  value={country}
  onChange={event =>
    setCountry(
      event.target.value
    )
  }
>
```

You can conditionally display another field:

```jsx
{country === "US" && (
  <input
    placeholder="State"
  />
)}
```

The form reacts immediately to user input.

That's where controlled fields shine.

---

# Form Validation ✅

Now we get to the part everyone loves.

Validation.

Or, more accurately:

> "How do we politely explain to the user that `abc` is not a valid password?" 😌

Validation means checking whether the submitted values satisfy the rules your application expects.

For example:

```text
Name
→ required

Email
→ required
→ should look like an email

Password
→ required
→ at least 8 characters

Confirm password
→ must match password
```

---

# Client-Side Validation vs Server Validation

This distinction is extremely important.

React validation improves user experience.

But **client-side validation must never be your only security validation**.

Why?

Because users control their browser.

They can bypass your React code and send requests directly to your server.

So:

```text
Client validation
       ↓
Fast user feedback

Server validation
       ↓
Actual trusted validation
```

Always validate important data on the backend too.

If your React form says:

```text
Password must contain 8 characters
```

that doesn't mean your server gets to say:

> "Well React checked it, so I guess we're good." 😂

The server must enforce its own rules.

---

# Validation on Submit

A straightforward approach is validating everything when the user submits.

Let's create:

```jsx
function validate(form) {
  const errors = {}

if (!form.name.trim()) {
    errors.name =
      "Name is required."
  }

if (!form.email.trim()) {
    errors.email =
      "Email is required."
  }

if (!form.password) {
    errors.password =
      "Password is required."
  }

return errors
}
```

The function returns:

```jsx
{}
```

when everything is valid.

Or something like:

```jsx
{
  email:
    "Email is required.",
  password:
    "Password is required."
}
```

when validation fails.

---

# Why Return an Error Object?

An error object lets each field have its own message.

For example:

```jsx
errors.email
```

belongs to the email input.

```jsx
errors.password
```

belongs to the password input.

Then JSX can render:

```jsx
{errors.email && (
  <p>
    {errors.email}
  </p>
)}
```

directly beside the relevant field.

That's much friendlier than:

```text
FORM INVALID
```

Good luck figuring out why. 😭

---

# Email Validation

You may see enormous regular expressions used to validate email addresses.

For a simple client-side check, you generally don't need to recreate the entire international email specification in one regex.

The browser already gives us:

```jsx
<input type="email" />
```

which provides basic email-format validation.

If you still want a lightweight custom check, something simple might look like:

```jsx
const emailPattern =
  /^[^\s@]+@[^\s@]+\.[^\s@]+$/
```

Then:

```jsx
if (
  !emailPattern.test(
    form.email
  )
) {
  errors.email =
    "Enter a valid email address."
}
```

Even then, remember:

> The only reliable way to know whether an email belongs to someone is usually to verify it through an email flow.

A regex cannot travel across the internet and ask the inbox whether it exists.

Would be impressive, though. 😂

---

# A Better Validation Function

```jsx
function validate(form) {
  const errors = {}

const name =
    form.name.trim()

const email =
    form.email.trim()

const emailPattern =
    /^[^\s@]+@[^\s@]+\.[^\s@]+$/

if (!name) {
    errors.name =
      "Name is required."
  } else if (
    name.length < 2
  ) {
    errors.name =
      "Name must be at least 2 characters."
  }

if (!email) {
    errors.email =
      "Email is required."
  } else if (
    !emailPattern.test(email)
  ) {
    errors.email =
      "Enter a valid email address."
  }

if (!form.password) {
    errors.password =
      "Password is required."
  } else if (
    form.password.length < 8
  ) {
    errors.password =
      "Password must be at least 8 characters."
  }

if (!form.confirmPassword) {
    errors.confirmPassword =
      "Please confirm your password."
  } else if (
    form.password !==
    form.confirmPassword
  ) {
    errors.confirmPassword =
      "Passwords do not match."
  }

if (!form.agreed) {
    errors.agreed =
      "You must accept the terms."
  }

return errors
}
```

This function doesn't touch React state.

It simply receives data and returns validation results.

That's nice because the validation logic is easier to test and understand.

---

# Registration Form State

```jsx
const [form, setForm] =
  useState({
    name: "",
    email: "",
    password: "",
    confirmPassword: "",
    agreed: false
  })

const [errors, setErrors] =
  useState({})

const [submitted, setSubmitted] =
  useState(false)
```

We have separate responsibilities:

```text
form
 ↓
Current user input

errors
 ↓
Current validation messages

submitted
 ↓
Whether this demo completed successfully
```

---

# Handling Submission

```jsx
function handleSubmit(event) {
  event.preventDefault()

const validationErrors =
    validate(form)

if (
    Object.keys(
      validationErrors
    ).length > 0
  ) {
    setErrors(
      validationErrors
    )

return
  }

setErrors({})

console.log(
    "Submitting:",
    form
  )

setSubmitted(true)
}
```

The important flow is:

```text
User submits
     ↓
Prevent normal browser submission
     ↓
Validate form
     ↓
Errors?
  /       \
Yes       No
 ↓         ↓
Show      Continue
errors    submission
```

---

# Why Check `Object.keys(errors).length`?

Suppose:

```jsx
validationErrors = {}
```

Then:

```jsx
Object.keys(
  validationErrors
)
```

returns:

```jsx
[]
```

and:

```jsx
.length
```

is:

```text
0
```

No errors.

But:

```jsx
{
  email:
    "Email is required."
}
```

produces:

```jsx
["email"]
```

with length:

```text
1
```

So:

```jsx
Object.keys(
  validationErrors
).length > 0
```

means:

> "Did validation find at least one problem?"

---

# Complete Registration Form

```jsx
import { useState } from "react"

function RegistrationForm() {
  const [form, setForm] =
    useState({
      name: "",
      email: "",
      password: "",
      confirmPassword: "",
      agreed: false
    })

const [errors, setErrors] =
    useState({})

const [submitted, setSubmitted] =
    useState(false)

function update(
    field,
    value
  ) {
    setForm(previous => ({
      ...previous,
      [field]: value
    }))

if (errors[field]) {
      setErrors(previous => ({
        ...previous,
        [field]: ""
      }))
    }
  }

function validate() {
    const newErrors = {}

const name =
      form.name.trim()

const email =
      form.email.trim()

const emailPattern =
      /^[^\s@]+@[^\s@]+\.[^\s@]+$/

if (!name) {
      newErrors.name =
        "Name is required."
    } else if (
      name.length < 2
    ) {
      newErrors.name =
        "Name must be at least 2 characters."
    }

if (!email) {
      newErrors.email =
        "Email is required."
    } else if (
      !emailPattern.test(email)
    ) {
      newErrors.email =
        "Enter a valid email address."
    }

if (!form.password) {
      newErrors.password =
        "Password is required."
    } else if (
      form.password.length < 8
    ) {
      newErrors.password =
        "Password must be at least 8 characters."
    }

if (
      !form.confirmPassword
    ) {
      newErrors.confirmPassword =
        "Please confirm your password."
    } else if (
      form.password !==
      form.confirmPassword
    ) {
      newErrors.confirmPassword =
        "Passwords do not match."
    }

if (!form.agreed) {
      newErrors.agreed =
        "You must accept the terms."
    }

return newErrors
  }

function handleSubmit(
    event
  ) {
    event.preventDefault()

const validationErrors =
      validate()

if (
      Object.keys(
        validationErrors
      ).length > 0
    ) {
      setErrors(
        validationErrors
      )

return
    }

setErrors({})

console.log(
      "Submitting:",
      form
    )

setSubmitted(true)
  }

if (submitted) {
    return (
      <div>
        ✅ Account created!

<p>
          Welcome, {form.name}.
        </p>
      </div>
    )
  }

return (
    <form
      onSubmit={handleSubmit}
      noValidate
    >
      <h2>
        Create Account
      </h2>

<input
          id="name"
          value={form.name}
          onChange={event =>
            update(
              "name",
              event.target.value
            )
          }
          aria-invalid={
            Boolean(
              errors.name
            )
          }
          aria-describedby={
            errors.name
              ? "name-error"
              : undefined
          }
        />

{errors.name && (
          <p
            id="name-error"
            role="alert"
          >
            {errors.name}
          </p>
        )}
      </div>

<div>
        <label
          htmlFor="email"
        >
          Email
        </label>

<input
          id="email"
          type="email"
          value={form.email}
          onChange={event =>
            update(
              "email",
              event.target.value
            )
          }
          aria-invalid={
            Boolean(
              errors.email
            )
          }
          aria-describedby={
            errors.email
              ? "email-error"
              : undefined
          }
        />

{errors.email && (
          <p
            id="email-error"
            role="alert"
          >
            {errors.email}
          </p>
        )}
      </div>

<div>
        <label
          htmlFor="password"
        >
          Password
        </label>

<input
          id="password"
          type="password"
          value={
            form.password
          }
          onChange={event =>
            update(
              "password",
              event.target.value
            )
          }
          aria-invalid={
            Boolean(
              errors.password
            )
          }
          aria-describedby={
            errors.password
              ? "password-error"
              : undefined
          }
        />

{errors.password && (
          <p
            id="password-error"
            role="alert"
          >
            {errors.password}
          </p>
        )}
      </div>

<div>
        <label
          htmlFor="confirmPassword"
        >
          Confirm Password
        </label>

<input
          id="confirmPassword"
          type="password"
          value={
            form.confirmPassword
          }
          onChange={event =>
            update(
              "confirmPassword",
              event.target.value
            )
          }
          aria-invalid={
            Boolean(
              errors.confirmPassword
            )
          }
          aria-describedby={
            errors.confirmPassword
              ? "confirm-error"
              : undefined
          }
        />

{errors.confirmPassword && (
          <p
            id="confirm-error"
            role="alert"
          >
            {
              errors.confirmPassword
            }
          </p>
        )}
      </div>

<div>
        <label>
          <input
            type="checkbox"
            checked={
              form.agreed
            }
            onChange={event =>
              update(
                "agreed",
                event.target.checked
              )
            }
          />

I agree to the terms
        </label>

{errors.agreed && (
          <p role="alert">
            {errors.agreed}
          </p>
        )}
      </div>

<button type="submit">
        Create Account
      </button>
    </form>
  )
}
```

There's quite a lot happening here, but it's all based on concepts you've already learned:

```text
State
Events
Conditional Rendering
Controlled Inputs
Validation
Accessibility
```

The form is just those ideas working together.

---

# Why Use Real `<label>` Elements?

It's tempting to rely on placeholders:

```jsx
<input
  placeholder="Email"
/>
```

But a placeholder is not a proper replacement for a label.

Better:

```jsx
<label htmlFor="email">
  Email
</label>

<input
  id="email"
/>
```

The:

```jsx
htmlFor="email"
```

connects the label to:

```jsx
id="email"
```

This improves accessibility and also lets users click the label to focus the input.

Remember from JSX:

```text
HTML
for

JSX
htmlFor
```

React has returned to test whether you remember previous chapters. 😌

---

# Making Validation Errors Accessible

Instead of communicating an invalid field only through:

```text
Red border
```

provide actual text.

Why?

Because not every user perceives color the same way.

This:

```jsx
<p>
  Email is required.
</p>
```

communicates the problem clearly.

We can also connect the input and error:

```jsx
aria-describedby="email-error"
```

with:

```jsx
<p id="email-error">
```

and mark the input:

```jsx
aria-invalid={true}
```

You don't need to become an accessibility expert overnight, but good form design should never rely only on color.

---

# Clearing Errors While the User Fixes Them

Suppose the user submits:

```text
Email: ""
```

and receives:

```text
Email is required.
```

Then they begin typing.

You could keep showing the old error until the next submission.

But sometimes it's nicer to clear that field's existing error once the user begins correcting it:

```jsx
function update(
  field,
  value
) {
  setForm(previous => ({
    ...previous,
    [field]: value
  }))

if (errors[field]) {
    setErrors(previous => ({
      ...previous,
      [field]: ""
    }))
  }
}
```

This means:

```text
Submit invalid field
       ↓
Show error
       ↓
User starts correcting field
       ↓
Clear old error
```

That's one valid UX strategy.

---

# Validation Timing

There are several common times to validate.

### On submit

```text
User finishes form
      ↓
Clicks Submit
      ↓
Validate everything
```

This is simple and avoids interrupting the user too early.

### On blur

```text
User leaves field
      ↓
Validate that field
```

This can provide feedback before submission without shouting at someone while they're still typing.

### On change

```text
Every value change
      ↓
Validate immediately
```

This is useful for some things, such as:

```text
Password strength
Character limits
Username availability
```

but can also become annoying.

Imagine typing the first letter of your email and immediately seeing:

```text
INVALID EMAIL!!! 🚨
```

Thank you, form.

I was getting there. 😭

---

# Real-Time Validation

Here's a simple field validator:

```jsx
function validateField(
  name,
  value
) {
  switch (name) {
    case "email": {
      if (!value.trim()) {
        return (
          "Email is required."
        )
      }

const emailPattern =
        /^[^\s@]+@[^\s@]+\.[^\s@]+$/

return emailPattern.test(
        value
      )
        ? ""
        : "Enter a valid email."
    }

case "password": {
      if (!value) {
        return (
          "Password is required."
        )
      }

return value.length >= 8
        ? ""
        : "Use at least 8 characters."
    }

default:
      return value.trim()
        ? ""
        : "This field is required."
  }
}
```

Then:

```jsx
function handleChange(
  event
) {
  const {
    name,
    value
  } = event.target

setForm(previous => ({
    ...previous,
    [name]: value
  }))

setErrors(previous => ({
    ...previous,

[name]:
      validateField(
        name,
        value
      )
  }))
}
```

Now each field can update its validation while the user types.

---

# Real-Time Validation Isn't Always Better

This is important.

More validation does not automatically equal better UX.

Imagine a password field showing:

```text
Password too short.
```

the instant the user types:

```text
a
```

Of course it's too short.

They literally just started. 😂

A better experience might be:

```text
Before interaction
    ↓
No error

User edits field
    ↓
Maybe show helpful guidance

User leaves field
    ↓
Show validation error if needed

User submits
    ↓
Validate everything
```

There is no universal validation timing that fits every form.

Design it around the user's task.

---

# Touched Fields

More advanced forms often track whether a field has been interacted with.

For example:

```jsx
const [touched, setTouched] =
  useState({})
```

Then:

```jsx
onBlur={() =>
  setTouched(previous => ({
    ...previous,
    email: true
  }))
}
```

The error might only display when:

```jsx
touched.email &&
errors.email
```

This avoids showing validation feedback before the user has had a chance to interact with the field.

We'll go deeper into patterns like this in the dedicated forms article.

---

# Browser Validation Is Useful Too

HTML already gives us validation tools:

```jsx
<input required />
```

```jsx
<input
  type="email"
  required
/>
```

```jsx
<input
  minLength={8}
/>
```

```jsx
<input
  type="number"
  min={18}
/>
```

You don't always need to rebuild every validation rule in [JavaScript](/courses/javascript).

Browser validation can be useful, especially for simple forms.

You can combine native constraints with application validation depending on your needs.

---

# What Does `noValidate` Do?

In our custom validation example, we used:

```jsx
<form noValidate>
```

That disables the browser's built-in validation UI for that form.

Why?

Because we wanted our own React error messages to control the experience.

If you're happy using browser-native validation, you don't need `noValidate`.

Again:

```text
Native validation
      ↓
Good for simple forms

Custom React validation
      ↓
Useful when you need custom behavior/UI
```

Choose intentionally.

---

# Uncontrolled Inputs With `FormData`

Refs aren't the only way to read uncontrolled form values.

The browser also provides:

```jsx
FormData
```

which can read form fields during submission.

For example:

```jsx
function ContactForm() {
  function handleSubmit(
    event
  ) {
    event.preventDefault()

const formData =
      new FormData(
        event.currentTarget
      )

const name =
      formData.get("name")

const email =
      formData.get("email")

console.log({
      name,
      email
    })
  }

return (
    <form
      onSubmit={handleSubmit}
    >
      <input
        name="name"
        placeholder="Name"
      />

<button type="submit">
        Send
      </button>
    </form>
  )
}
```

Notice there is no state for the fields.

The DOM stores the values.

On submission:

```jsx
new FormData(
  event.currentTarget
)
```

collects them.

This can be an elegant solution for forms where you don't need live React-controlled values.

---

# Why the `name` Attribute Matters With `FormData`

Consider:

```jsx
<input
  name="email"
/>
```

The:

```text
name
```

is what identifies the field in submitted form data.

So:

```jsx
formData.get("email")
```

reads the value of:

```jsx
name="email"
```

Without meaningful `name` attributes, form submission becomes much less useful.

This is normal HTML behavior, not something invented by React.

And that's worth remembering:

> React forms are still HTML forms.

React is helping you manage them, not replacing the platform underneath.

---

# Controlled vs Uncontrolled Example

Here's the same idea both ways.

Controlled:

```jsx
function ControlledForm() {
  const [email, setEmail] =
    useState("")

function handleSubmit(
    event
  ) {
    event.preventDefault()

console.log(email)
  }

return (
    <form
      onSubmit={handleSubmit}
    >
      <input
        value={email}
        onChange={event =>
          setEmail(
            event.target.value
          )
        }
      />

<button>
        Submit
      </button>
    </form>
  )
}
```

Uncontrolled:

```jsx
function UncontrolledForm() {
  function handleSubmit(
    event
  ) {
    event.preventDefault()

const formData =
      new FormData(
        event.currentTarget
      )

console.log(
      formData.get("email")
    )
  }

return (
    <form
      onSubmit={handleSubmit}
    >
      <input
        name="email"
      />

<button>
        Submit
      </button>
    </form>
  )
}
```

Neither is inherently incorrect.

The controlled version gives React immediate access to the value.

The uncontrolled version is simpler when you only need the value at submission time.

---

# When Controlled Inputs Make Sense

Controlled inputs are often a strong fit when you need:

```text
Live search
Live validation
Character counting
Conditional fields
Dependent fields
Formatting
Live preview
State shared with another component
Dynamic submit-button state
```

For example:

```jsx
<button
  disabled={
    !form.email ||
    !form.password
  }
>
  Login
</button>
```

That's easy because React already has the values.

---

# When Uncontrolled Inputs Make Sense

Uncontrolled inputs can be useful when:

```text
You only need values on submit
The form is simple
You are integrating with DOM-based code
You are working with file inputs
You want to use FormData directly
```

They can also reduce how much state-management code you need.

Don't mistake:

```text
Less React state
```

for:

```text
Bad React
```

Sometimes HTML already solved the problem.

---

# Avoid Switching Between Controlled and Uncontrolled

Suppose an input begins like:

```jsx
value={undefined}
```

and later becomes:

```jsx
value="Alice"
```

You've effectively changed it from uncontrolled to controlled.

Likewise, a controlled input shouldn't suddenly lose its value.

It's better to initialize controlled text fields with:

```jsx
""
```

For example:

```jsx
const [name, setName] =
  useState("")
```

rather than:

```jsx
const [name, setName] =
  useState()
```

when the value is going directly into a controlled text input.

Keep the ownership model consistent.

---

# Submitting Data to an API

Validation is only one part of a real form.

Eventually, you may submit to a backend.

Conceptually:

```jsx
async function handleSubmit(
  event
) {
  event.preventDefault()

const validationErrors =
    validate()

if (
    Object.keys(
      validationErrors
    ).length > 0
  ) {
    setErrors(
      validationErrors
    )

return
  }

await fetch(
    "/api/register",
    {
      method: "POST",

headers: {
        "Content-Type":
          "application/json"
      },

body: JSON.stringify(
        form
      )
    }
  )
}
```

Now your form starts connecting several chapters:

```text
Forms
  ↓
Validation
  ↓
Events
  ↓
State
  ↓
Data Fetching
  ↓
Loading / Success / Error
```

Real React applications are basically previous chapters teaming up against you. 😂

---

# Form Submission Has Its Own States

Just like data fetching, a form submission can be:

```text
Idle
Submitting
Success
Error
```

So you may have:

```jsx
const [status, setStatus] =
  useState("idle")
```

Then:

```jsx
setStatus("submitting")
```

before the request.

On success:

```jsx
setStatus("success")
```

On failure:

```jsx
setStatus("error")
```

This lets the button show:

```text
Create Account
```

then:

```text
Creating Account...
```

and disables duplicate submissions.

---

# Disable Submit During a Request

```jsx
<button
  type="submit"
  disabled={
    status === "submitting"
  }
>
  {status === "submitting"
    ? "Creating Account..."
    : "Create Account"}
</button>
```

This prevents someone from clicking:

```text
Create Account
Create Account
Create Account
Create Account
```

because they became impatient after 0.7 seconds.

Users are fast.

APIs are sometimes not. 😭

---

# Server Errors Belong in the Form Too

Suppose client validation succeeds.

Then the backend responds:

```text
Email address already registered.
```

That's not the same as a local format-validation error.

Your form should be ready to display server errors too.

For example:

```jsx
setErrors(previous => ({
  ...previous,
  email:
    "An account already exists with this email."
}))
```

Client validation improves UX.

Server validation remains authoritative.

Both need to work together.

---

# Common Beginner Mistakes 🚨

## Mistake 1: Assuming Controlled Is Always Better

Controlled inputs are useful.

But:

```text
Controlled = always professional
Uncontrolled = bad
```

is not a useful rule.

Choose based on whether React actually needs to track the value.

---

## Mistake 2: Forgetting `onChange`

This:

```jsx
<input
  value={name}
/>
```

without updating `name` behaves like a read-only controlled input.

Use:

```jsx
<input
  value={name}
  onChange={event =>
    setName(
      event.target.value
    )
  }
/>
```

when it should be editable.

---

## Mistake 3: Using `value` for a Checkbox's Boolean State

Wrong mental model:

```jsx
<input
  type="checkbox"
  value={agreed}
/>
```

For controlled checked state:

```jsx
<input
  type="checkbox"
  checked={agreed}
  onChange={event =>
    setAgreed(
      event.target.checked
    )
  }
/>
```

Think:

```text
Text-like input
      ↓
value

Checkbox/radio selection
      ↓
checked
```

---

## Mistake 4: Assuming Number Inputs Produce Numbers

This:

```jsx
event.target.value
```

can still be:

```js
"42"
```

Convert when appropriate:

```jsx
const age =
  Number(form.age)
```

Don't discover this when:

```jsx
"2" + "2"
```

enthusiastically gives you:

```text
22
```

JavaScript remains committed to keeping developers humble. 😌

---

## Mistake 5: Mutating the Form Object

Wrong:

```jsx
form.email =
  "alice@example.com"

setForm(form)
```

Better:

```jsx
setForm(previous => ({
  ...previous,
  email:
    "alice@example.com"
}))
```

Treat React state as read-only.

---

## Mistake 6: Validating Only With Color

This:

```text
Red border
```

doesn't explain what went wrong.

Use a message:

```jsx
{errors.email && (
  <p>
    {errors.email}
  </p>
)}
```

Color can reinforce the message, but shouldn't be the only information.

---

## Mistake 7: Trusting Client Validation for Security

Never assume:

```text
React validated it
      ↓
Safe forever
```

Users can bypass the frontend.

Your server must validate important submitted data independently.

Frontend validation is user experience.

Backend validation is trust and security.

---

## Mistake 8: Validating Aggressively Before the User Can Type

Showing:

```text
INVALID EMAIL
```

after the user types:

```text
a
```

is technically correct and emotionally unnecessary.

Choose validation timing thoughtfully.

---

## Mistake 9: Forgetting Empty Strings

Controlled text inputs commonly work nicely with:

```jsx
""
```

as their initial value.

For example:

```jsx
const [email, setEmail] =
  useState("")
```

This keeps the field controlled from the beginning.

---

# A Better Mental Model 🧠

Controlled input:

```text
React State
    ↓
Input value
    ↓
User types
    ↓
onChange
    ↓
React State
```

It's a loop.

Uncontrolled input:

```text
DOM
 ↓
Stores value while user types
 ↓
React reads it when needed
```

Validation:

```text
Form values
    ↓
Validation rules
    ↓
Errors?
  /       \
Yes       No
 ↓         ↓
Show      Submit
feedback  data
```

Real submission:

```text
User submits
      ↓
Client validation
      ↓
Valid?
   /      \
 No       Yes
 ↓         ↓
Errors   Send request
             ↓
       Server validation
             ↓
       Success / Error
```

That's the complete picture.

---

# Quick Forms Cheat Sheet 🚀

Controlled text:

```jsx
const [name, setName] =
  useState("")

<input
  value={name}
  onChange={event =>
    setName(
      event.target.value
    )
  }
/>
```

Controlled checkbox:

```jsx
const [agreed, setAgreed] =
  useState(false)

<input
  type="checkbox"
  checked={agreed}
  onChange={event =>
    setAgreed(
      event.target.checked
    )
  }
/>
```

Controlled select:

```jsx
<select
  value={role}
  onChange={event =>
    setRole(
      event.target.value
    )
  }
>
```

Controlled textarea:

```jsx
<textarea
  value={bio}
  onChange={event =>
    setBio(
      event.target.value
    )
  }
/>
```

Radio:

```jsx
<input
  type="radio"
  value="pro"
  checked={plan === "pro"}
  onChange={event =>
    setPlan(
      event.target.value
    )
  }
/>
```

File:

```jsx
<input
  type="file"
  onChange={event =>
    setFile(
      event.target.files?.[0]
      || null
    )
  }
/>
```

Uncontrolled with a ref:

```jsx
const inputRef =
  useRef(null)

<input ref={inputRef} />
```

Read:

```jsx
inputRef.current.value
```

Uncontrolled with `FormData`:

```jsx
const formData =
  new FormData(
    event.currentTarget
  )

const email =
  formData.get("email")
```

---

# Chapter Summary 🎯

React forms can use either **controlled** or **uncontrolled** inputs.

A controlled input stores its current value in React state:

```jsx
const [email, setEmail] =
  useState("")
```

Then:

```jsx
<input
  value={email}
  onChange={event =>
    setEmail(
      event.target.value
    )
  }
/>
```

The flow is:

```text
State
 ↓
Input
 ↓
User interaction
 ↓
onChange
 ↓
State
```

Controlled fields are particularly useful when your application needs to react to the current value while the user is editing.

That includes things such as:

```text
Live validation
Character counters
Conditional fields
Live previews
Dependent inputs
Search/filtering
```

Uncontrolled inputs let the browser keep the current value.

You can read it with:

```jsx
useRef()
```

or:

```jsx
FormData
```

when you actually need it.

So don't memorize:

```text
Controlled = good
Uncontrolled = bad
```

Instead:

> **Use controlled inputs when React needs the current value. Use uncontrolled inputs when letting the DOM manage the value makes the form simpler.**

Different input types also need slightly different handling.

Text-like controls usually use:

```jsx
value
```

Checkboxes and radio buttons use:

```jsx
checked
```

and file selections come from:

```jsx
event.target.files
```

For validation, a useful basic flow is:

```text
Submit
  ↓
Validate
  ↓
Errors?
 /     \
Yes    No
 ↓      ↓
Show   Continue
them   submission
```

Validation errors should be specific and placed near the relevant field.

Instead of:

```text
Invalid form.
```

prefer:

```text
Email is required.

Password must contain at least 8 characters.

Passwords do not match.
```

And remember one of the most important form rules:

> **Client-side validation improves the user experience, but the server must still validate submitted data independently.**

React controls the interface.

It does not create a magical security wall around your API.

---

# Forms Are Really Several React Concepts Together

Forms feel like a separate topic, but look at what you're actually using:

```text
useState 🧠
Stores form values and errors

Events ⚡
Handles typing and submission

Conditional Rendering 🤔
Shows validation feedback

Arrays & Objects 📦
Store related form information

useRef 📌
Can read uncontrolled elements

Data Fetching 🌐
Submits information to APIs
```

That's an important milestone.

You aren't learning isolated React features anymore.

You're combining them to solve real interface problems.

---

# What We'll Cover in the Dedicated Forms Article 🔬

This chapter gives you enough to build useful forms, but forms can become a very deep topic.

In the dedicated article, we can go further into:

```text
Touched fields
Dirty fields
Validation on blur
Form-level errors
Server errors
Async validation
Debounced username checks
Password strength indicators
Dynamic fields
Dependent fields
Multi-step forms
File uploads
FormData
Accessibility
Reusable field components
useReducer for larger forms
Schema validation
Form libraries
React 19 form actions
Pending submission state
```

Those are worth understanding properly rather than squeezing all of them into one chapter until the learner begins reconsidering web development as a career. 😂

For now, focus on the foundation:

```text
Who owns the value?

When should I validate it?

How should I communicate errors?

What happens when the user submits?
```

If you can answer those questions, you already understand the most important part of React forms.

---

# Keep Learning With asif.to 🚀

Your React toolkit is now getting dangerously close to something you can use to build real applications:

```text
Components 🧩
Reusable UI

Props 📦
Pass data

State 🧠
Store changing values

Events ⚡
Respond to users

Lists 📋
Render collections

Conditional Rendering 🤔
Control what appears

Effects 🔄
Synchronize external systems

Context 🌍
Share application data

Router 🧭
Create navigation

Data Fetching 🌐
Talk to APIs

Forms 📝
Collect and validate user input
```

Forms are one of the best places to practice React because they force several concepts to work together.

Build a login form.

Then build a registration form.

Then add inline validation.

Then add a loading state.

Then fake a server error.

Then add a file upload.

And somewhere around the third password-validation requirement, you'll begin to understand why entire libraries exist just to manage forms. 😭

For more beginner-friendly React lessons, practical examples, and dedicated deep dives into forms and validation, visit **asif.to**.

Follow **asif.to** on its social handles too for shorter programming explanations, React examples, and practical web-development tips that focus on understanding what the code is doing rather than just collecting [Hooks](/courses/reactjs/chapter-11-advanced-hooks-useref-usereducer-usememo-usecallback) like Pokémon. 😄

**Let React control what needs control. Let HTML do what HTML already does well. Validate clearly, submit carefully, and never trust the browser as your security layer. 🚀**

— **asif.to**
</article></body></html>