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.

Sitelet https://gitgood.dev/coding/dom-form-validation

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.