Unit 4: Form Handling and Validation - Subjective Questions

Controlled components are form elements whose values are managed by React state. The input value is assigned from state, and an onChange event updates that state whenever the user types.

Uncontrolled components store their current values in the DOM. React accesses the values when required, commonly by using a ref and the FormData API.

Comparison:

• Controlled components provide immediate access to form data and make validation easier.
• Uncontrolled components require less state management and can be convenient for simple forms.
• A controlled component is suitable for dynamic forms with live validation.
• An uncontrolled component is suitable for a small form that only needs values at submission time.

A controlled text input receives its displayed value from React state and updates that state through an event handler.

const [name, setName] = useState("");

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

• The value property ensures that the input always reflects the current React state.
• The onChange handler runs whenever the user modifies the field.
• event.target.value contains the latest input value.
• Calling setName triggers a re-render with the updated value.
• This pattern gives the application complete control over the input and supports live validation, formatting, and conditional behavior.

Controlled and uncontrolled components differ in how form data is stored and accessed.

Controlled inputs provide greater predictability and flexibility, while uncontrolled inputs can reduce code for forms with limited interaction requirements.

Three common form state management patterns are:

• Individual state variables: Each field has its own useState variable. This is simple and readable for small forms with only a few fields.
• Single state object: All field values are stored in one object, such as { name, email, password }. This is useful when fields are related and can be updated through a shared change handler.
• Reducer-based state management: useReducer stores values, errors, touched states, and submission status in a structured state object. It is appropriate for large or complex forms with many state transitions.

The selected pattern should match the form's complexity. Using a reducer for a two-field form may add unnecessary complexity, whereas using separate state variables for a multi-step form may become difficult to maintain.

A generic change handler identifies the changed field using the input's name attribute and updates only that property in the form state.

const [formData, setFormData] = useState({
  name: "",
  email: ""
});

function handleChange(event) {
  const { name, value } = event.target;
  setFormData((previous) => ({
    ...previous,
    [name]: value
  }));
}

Each input must have a matching name attribute:

<input name="name" value={formData.name} onChange={handleChange} />
<input name="email" value={formData.email} onChange={handleChange} />

The spread operator preserves unchanged fields, while the computed property name updates only the field that generated the event.

A reliable submission workflow generally follows these steps:

1. Attach an onSubmit handler to the <form> element.
2. Call event.preventDefault() to prevent the browser's default page reload.
3. Read the current form state or construct a FormData object.
4. Validate the submitted values before contacting the server.
5. Set a submitting flag to prevent duplicate submissions and provide feedback.
6. Send the valid data to an API using an asynchronous request.
7. On success, show confirmation, reset the form, or navigate to another view.
8. On failure, display a general error and preserve the entered values.
9. Clear the submitting state in a finally block.

The workflow should also handle network failures, server-side validation errors, and unexpected responses without losing useful user input.

Reusable form components encapsulate repeated input behavior and presentation so that forms remain consistent and easier to maintain.

A reusable input component should generally support:

• A clear label associated with the input.
• A unique name and id.
• A value and onChange callback for controlled usage.
• An optional onBlur callback for touched-state tracking.
• An error message and visual error state.
• A disabled or required property when appropriate.
• An inputType, placeholder, and other native input attributes.
• Accessible descriptions through aria-describedby.

The component should remain flexible and avoid embedding business-specific validation or API logic. Form-specific rules should normally be supplied by the parent form or a validation schema.

A reusable input component focuses on one field, while a reusable form component coordinates a collection of fields and the submission process.

• Reusable input component: Renders a label, input control, helper text, and field-level error. It accepts values and event handlers through props.
• Reusable form component: Manages form values, validation, submission state, API interaction, reset behavior, and form-level errors.
• Parent or feature component: Supplies domain-specific fields, validation rules, and the action to execute after successful submission.

This separation follows the principle of single responsibility. It allows the same input component to be used for registration, profile editing, and search forms while keeping domain logic outside the visual field component.

Conditional rendering displays different form elements depending on values such as the selected option, authentication status, validation result, or submission state.

Examples include:

• Showing an address field only when the user selects Home delivery.
• Displaying a password confirmation field during registration but not during login.
• Rendering an error message only when a field has an error.
• Disabling the submit button while a request is in progress.
• Showing a success message after a successful submission.

{formData.deliveryMethod === "home" && (
  <input name="address" value={formData.address} onChange={handleChange} />
)}

{errors.email && <p role="alert">{errors.email}</p>}

Conditional fields should be handled carefully so that hidden values do not accidentally get submitted or validated when they are no longer relevant.

Accessible form handling ensures that users with different abilities can understand, complete, and correct a form.

Important considerations include:

• Associate every input with a visible <label> using matching htmlFor and id values.
• Provide clear instructions and meaningful placeholder-independent labels.
• Use appropriate native input types such as email, number, and password.
• Connect error and help text using aria-describedby.
• Set aria-invalid="true" when a field contains an error.
• Use role="alert" or an appropriate live region for important validation feedback.
• Preserve keyboard navigation and visible focus indicators.
• Avoid relying only on color to communicate errors.
• Place error messages near the relevant controls.
• Ensure that dynamically added fields and submission results are announced appropriately.

Native HTML form semantics should be preferred before adding ARIA attributes.

Client-side validation checks user input in the browser before or during form submission. React applications can validate values as the user types, when a field loses focus, or when the form is submitted.

Benefits:

• Provides immediate feedback.
• Reduces unnecessary requests to the server.
• Improves the user experience.
• Helps prevent obviously incomplete or malformed submissions.
• Supports interactive interfaces such as conditional validation.

Limitations:

• It can be bypassed or disabled by a malicious user.
• It does not replace server-side validation.
• Complex validation may affect performance if performed on every keystroke.
• Client and server rules can become inconsistent if they are not designed carefully.

Therefore, client-side validation improves usability, while the server remains responsible for enforcing data integrity and security.

Common validation patterns include:

• Required-field validation: Checks that a value is not empty or only whitespace.
• Format validation: Verifies formats such as email addresses, URLs, phone numbers, or postal codes.
• Length and range validation: Enforces minimum and maximum lengths or numeric boundaries.
• Cross-field validation: Compares related values, such as ensuring that password confirmation matches the password.
• Touched-state validation: Displays errors after a user has interacted with a field, reducing distracting messages on initial render.
• Submit-time validation: Runs a complete validation pass when the user submits the form.
• Server-error validation: Maps errors returned by the server to the appropriate fields or to a form-level message.

A practical form often combines touched-state validation for field feedback with complete validation during submission.

Validation on change runs whenever the value changes. It provides immediate feedback but may show errors while the user is still typing and can cause excessive computation.

Validation on blur runs when the user leaves a field. It usually provides a better balance because the user has finished an interaction with that field, although errors may not appear until focus moves elsewhere.

Validation on submit runs when the user attempts to submit. It keeps the interface quiet while the form is being completed and guarantees a final validation pass, but it may delay useful feedback.

A robust design commonly uses:

• Basic or lightweight checks on change when necessary.
• Field validation on blur after interaction.
• Complete schema validation on submit.

The chosen strategy should reflect the form's complexity and the cost of displaying or computing validation results.

Schema-based validation defines the expected structure, data types, and constraints of form data in one declarative schema.

A schema can specify that:

• name must be a non-empty string.
• email must have a valid email format.
• age must be a number within an allowed range.
• password must meet minimum length requirements.
• confirmPassword must match password.

Schema-based validation improves maintainability because:

• Rules are centralized instead of scattered across event handlers.
• The same schema can be used for submission and field-level validation.
• Error results have a predictable structure.
• Changes to requirements are easier to apply.
• Schemas can often provide type inference in TypeScript.
• Validation logic becomes easier to test independently of the UI.

Zod is a TypeScript-friendly schema validation library that allows developers to define rules using composable schema objects.

import { z } from "zod";

const registrationSchema = z.object({
  name: z.string().trim().min(2, "Name must contain at least 2 characters"),
  email: z.string().email("Enter a valid email address"),
  password: z.string().min(8, "Password must contain at least 8 characters"),
  confirmPassword: z.string()
}).refine((data) => data.password === data.confirmPassword, {
  message: "Passwords must match",
  path: ["confirmPassword"]
});

The schema describes the complete data shape. Zod can validate it with safeParse, which returns either a successful result containing parsed data or a failure result containing structured validation issues. The refine method supports rules involving multiple fields.

parse and safeParse both validate data against a Zod schema, but they report results differently.

• parse: Returns the validated and potentially transformed data when validation succeeds. When validation fails, it throws a ZodError.
• safeParse: Returns an object describing the result. A successful result has success: true and contains data; a failed result has success: false and contains error.

For form validation, safeParse is often more convenient because expected validation failures can be handled as normal control flow rather than exceptions.

const result = registrationSchema.safeParse(formData);

if (!result.success) {
  // Convert result.error.issues into field-level errors.
} else {
  // Submit result.data.
}

parse can still be useful when invalid data represents an exceptional programming condition or when it is handled inside a controlled try...catch block.

A typical integration follows this process:

1. Keep the form values in controlled state or collect them with FormData.
2. Call schema.safeParse(values) inside the submit handler.
3. If validation fails, iterate over the issues returned by Zod.
4. Map each issue's path to the corresponding field name.
5. Store the mapped errors in React state.
6. Render each error beside its field.
7. Stop submission when errors exist.
8. If validation succeeds, submit the parsed data to the server.

const result = schema.safeParse(formData);

if (!result.success) {
  const nextErrors = {};
  result.error.issues.forEach((issue) => {
    const field = issue.path[0];
    if (typeof field === "string") nextErrors[field] = issue.message;
  });
  setErrors(nextErrors);
  return;
}

await submitToServer(result.data);

Using parsed data is preferable because schemas may trim, coerce, or transform values before submission.

Zod reports validation failures as an array of issues. Each issue commonly contains a path, a message, and a validation code. React form interfaces usually require an object keyed by field names.

For example, an issue with the path ["email"] and the message "Invalid email" can be converted to:

{
  email: "Invalid email"
}

A transformation function can be written as follows:

function toFieldErrors(issues) {
  return issues.reduce((errors, issue) => {
    const fieldName = issue.path.join(".");
    if (!errors[fieldName]) {
      errors[fieldName] = issue.message;
    }
    return errors;
  }, {});
}

Nested paths can be represented with dot notation. Form-level issues with an empty path should be stored separately so they can be displayed near the submit control or form heading.

A complex form should track separate aspects of its lifecycle:

• Values: The current data entered by the user.
• Errors: Client-side or server-side messages associated with fields or the whole form.
• Touched fields: Fields that the user has focused and left, used to control when errors appear.
• Submitting status: Indicates that validation or an API request is in progress and prevents duplicate submissions.
• Submission result: Stores success messages, returned records, or navigation decisions.
• Server error: Represents network failures or errors that cannot be assigned to one field.

These values can be managed with multiple state variables for a small form or with useReducer for a larger one. State transitions should be predictable: changing a field may clear its old error, submission should set isSubmitting, and completion should reset that flag regardless of success or failure.

Conditional validation applies rules only when another field has a particular value. For example, an apartment number may be required only when the user selects apartment as the residence type.

const addressSchema = z.object({
  residenceType: z.enum(["house", "apartment"]),
  apartmentNumber: z.string().optional()
}).superRefine((data, context) => {
  if (data.residenceType === "apartment" && !data.apartmentNumber?.trim()) {
    context.addIssue({
      code: z.ZodIssueCode.custom,
      path: ["apartmentNumber"],
      message: "Apartment number is required"
    });
  }
});

The field can also be conditionally rendered in the interface. The validation schema must match that behavior so hidden or irrelevant fields do not produce confusing errors.