Skip to content
tezvyn:

How would you implement real-time client-side validation in React?

Source: react.devMediumHow cards are made

How would you implement real-time client-side validation in React?

Tests state-driven UI thinking over imperative DOM updates. A strong answer uses a status enum like typing or error, derives validation from state instead of redundant booleans, and conditionally renders feedback.

What's really being asked

This question probes whether you think in state-driven UI patterns rather than imperative jQuery-style DOM manipulation. The interviewer wants to see if you model the input as a finite set of visual states such as empty, typing, invalid, or valid, and derive the interface from that state rather than toggling elements directly.

The full answer

First, use a single status state variable such as typing, submitting, or error to represent the current visual mode rather than a collection of unrelated booleans. Second, keep the raw input value in state with useState and compute validation errors from that value during render or inside an event handler, avoiding redundant state like an errorMessage string that duplicates information already present in the input. Third, provide real-time feedback by validating on change or blur events rather than only on submit, but debounce expensive checks if necessary, for example waiting 300 milliseconds after the user stops typing before running a regex. Fourth, render error messages conditionally based on the derived validation result and status state, ensuring the message is accessible via aria-live or role alert. Fifth, disable the submit button when status is submitting or when validation fails, deriving disabled state from the same source of truth.

The mistakes people make

A red flag is storing multiple boolean flags such as isEmpty, isTooShort, and hasInvalidChars in separate useState calls, which forces you to manually synchronize them on every keystroke and invites stale state bugs. Another anti-pattern is mutating the DOM directly with refs to show or hide error text instead of letting React re-render based on state. Candidates also sometimes store computed values like fullName when firstName and lastName already exist, violating the principle that state should not contain redundant information.

What usually comes next

The interviewer might ask how you would preserve or reset validation state when the component unmounts and remounts, how you would share validation logic across multiple form fields without prop drilling, or how you would handle async validation such as checking username availability against an API.

A concrete example

Suppose you are building an email input. You would store the email string in useState initialized to an empty value and store a status string initialized to typing. During render you compute isValid by checking whether the email includes an at symbol and has length greater than five. The error message renders only when status is error or when the user has blurred the field and isValid is false, using a paragraph element with an alert role. You never store isValid or the error message in state because both can be derived directly from the email value.

Interview question

When building real-time email validation in React, which state strategy best follows declarative, state-driven patterns?

  • a.Store the raw input in useState alongside separate booleans like isEmpty and isTooShort that update on every keystroke.
  • b.Store the raw input in useState and cache derived validation results like isValid and errorMessage in state to prevent recomputation.
  • c.Use a ref to access the input and imperatively toggle error message visibility in the DOM on blur events.
  • d.Store the raw input in useState, use a single status enum such as typing or error, and derive validation during render.Correct
Why?

The correct approach uses a single status enum and derives validation during render, avoiding redundant state. Option A is wrong because multiple boolean flags require manual synchronization and invite stale state bugs.

Just read this? Test yourself on what you have been reading.

Read the original → react.dev

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.

See open roles