How do you approach DOM: Validate a Form and Mark the Errors?

form.querySelectorAll('input') in document order; input.hasAttribute('required'), input.type, input.minLength (-1 when unset) are all available.

What are common mistakes on DOM: Validate a Form and Mark the Errors?

An incomplete dependency array, which pins the effect to a stale closure. Mutating state in place instead of replacing it, so no re-render is scheduled. Never cleaning up the timer, listener or subscription on unmount.

gitGood.dev

← Back to problems

DOM: Validate a Form and Mark the Errors

MediumFrontend Frameworks

Description

> **Runs in a real DOM.** Each test seeds a `<form id="signup">` before calling your function. Implement `validateForm()` that validates every `<input>` inside `#signup` against its own attributes: - `required`: the value must be non-empty after trimming. - `type="email"`: a non-empty value must look like `name@domain.tld`. - `minlength="N"`: a **non-empty** value must have at least N characters (an empty optional field is fine - same as the browser). For each invalid input set `aria-invalid="true"` and put a non-empty message into the element with `data-error-for="<input name>"`. For each valid input remove `aria-invalid` and clear that message (fields can start out already flagged). Return `{ invalid, ariaInvalid }`: `invalid` is the invalid field names in document order, and `ariaInvalid` is the names of the inputs whose `aria-invalid` attribute is `"true"` read back from the DOM after you are done.

Example 1

Input: name="" (required), email="pat@example.com", password="short" (minlength 8)

Output: {"invalid":["name","password"],"ariaInvalid":["name","password"]}

Constraints

- All inputs have a unique name and a matching [data-error-for] element. - Use a simple email check: one @, something before it, a dot somewhere after it.

DOM: Validate a Form and Mark the Errors: approach, complexity and pitfalls

A medium frontend problem, graded against 5 test cases (2 of them hidden).

The pattern: Frontend

React and browser-platform problems - hooks, event handling, and rendering behaviour.

Reach for it when you see: A component, hook, or DOM-behaviour question rather than an algorithm.

If you are stuck

Show the 3-step hint ladder

form.querySelectorAll('input') in document order; input.hasAttribute('required'), input.type, input.minLength (-1 when unset) are all available.
minlength only applies when the value is non-empty - that is how browsers treat an optional field.
Both branches must write: set aria-invalid + message when invalid, removeAttribute + empty the message when valid. tc2 starts with a stale error.

The optimal approach

Show the approach: Validation is two jobs: deciding, and reporting

Most candidates get the deciding right and forget half the reporting. The two things that separate a good answer:

1. Clear the valid state too. A field that was invalid on the last submit and is fixed now must lose `aria-invalid` and its message, or the form shows a stale error forever. Write both branches every time.

2. Match browser semantics. `minlength` does not apply to an empty optional field, and `required` is about the trimmed value. Copying the browser keeps your custom validation and the native `:invalid` pseudo-class in agreement.

`aria-invalid="true"` plus a message element that the input points at via `aria-describedby` is the accessible pattern; the message is what a screen reader announces when the field gets focus.

Time: O(inputs).

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

Common Frontend mistakes

These apply to the pattern as a whole, not just this problem.

An incomplete dependency array, which pins the effect to a stale closure.
Mutating state in place instead of replacing it, so no re-render is scheduled.
Never cleaning up the timer, listener or subscription on unmount.