yoklainterview sim
ProgressHistory

Frontend React Forms Suspense Interview Questions

75 verified Frontend React Forms Suspense interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

React Forms SuspenseDifficulty 2
function EmailField() {
  return <input type="email" value="[email protected]" />;
}

What happens when a user tries to edit this field in the browser?
  • aIt updates normally on every keystroke, but the parent component never re-renders because of it.
  • bReact throws a synchronous render error, and the whole component tree unmounts immediately.
  • cThe field behaves as read-only, and React logs a dev warning about a missing onChange handler.✓
  • dReact silently converts the field into an uncontrolled input the first time a key is pressed.
Explanation:A value prop makes an input controlled by React, and there's no onChange to feed a new value back in, so React keeps pinning the displayed text to "[email protected]" no matter what is typed — the field is effectively read-only. React also logs: "You provided a value prop to a form field without an onChange handler. This will render a read-only field." Fix by adding onChange, using readOnly explicitly, or switching to defaultValue for an uncontrolled field.
React Forms SuspenseDifficulty 2
<input value={query} onChange={handleChange} />
// on a later render, query becomes undefined

What does React do when a controlled input's value prop goes from a defined string to undefined?
  • aIt keeps the input controlled and silently treats undefined as an empty string, no warnings involved.
  • bIt switches the input to uncontrolled and logs a dev warning about changing from controlled to uncontrolled.✓
  • cIt throws immediately and stops rendering the whole application tree without any recovery.
  • dIt ignores the new undefined value entirely and keeps showing whatever string was there before, unchanged.
Explanation:React logs: "A component is changing a controlled input to be uncontrolled. This is likely caused by the value changing from a defined to undefined, which should not happen." From that point on, the DOM manages the field's value itself and React no longer drives it — a component must stay controlled or uncontrolled for its whole lifetime, never switch mid-way.
React Forms SuspenseDifficulty 1
In plain HTML, a text input's native change event typically fires only when the field loses focus after its value changed. Which statement about React's onChange prop on an <input> is correct?
  • aIt fires on every keystroke, because React's onChange corresponds to the browser's native input event.✓
  • bIt only fires once on blur, exactly matching the native change event's timing and behavior in plain HTML.
  • cIt fires exactly once, right after the component mounts, regardless of any typing.
  • dIt fires only when the user presses the Enter key while the field is focused.
Explanation:React's onChange is intentionally named after the HTML attribute but wired to the native input event under the hood, so it fires on every keystroke (and on paste, cut, etc.) rather than waiting for blur like a native change listener would. This is why onChange is the standard way to keep controlled input state in sync as the user types.
React Forms SuspenseDifficulty 2
function ProfileForm() {
  const [form, setForm] = useState({ name: '', email: '' });

  function handleChange(e) {
    const { name, value } = e.target;
    setForm(prev => ({ ...prev, [name]: value }));
  }

  return (
    <>
      <input name="name" value={form.name} onChange={handleChange} />
      <input name="email" value={form.email} onChange={handleChange} />
    </>
  );
}

Why does this pattern let one handleChange function drive both inputs correctly?
  • aReact automatically merges any two sibling inputs sharing the same handler into a single state field.
  • bThe name attribute is only used for accessibility labels; the real routing comes from input order.
  • ce.target.value returns an array of both inputs' values, which setForm then splits by position.
  • de.target.name identifies which input fired the event, so [name]: value updates only that one key.✓
Explanation:e.target is the DOM input that triggered the change, so e.target.name reads back the name attribute of that specific field. Using it as a computed property key ([name]: value) inside the spread lets a single handler update exactly the matching key in the form object while leaving the rest of the state untouched.
React Forms SuspenseDifficulty 1
function SearchForm({ onSearch }) {
  function handleSubmit(e) {
    onSearch();
  }
  return (
    <form onSubmit={handleSubmit}>
      <button type="submit">Search</button>
    </form>
  );
}

Clicking the button triggers a full page reload before onSearch seems to take effect. What is missing from handleSubmit?
  • aThe button needs type="button" instead of type="submit" so the form doesn't submit at all.
  • be.preventDefault() is missing, so the browser performs its default form submission and navigates.✓
  • chandleSubmit needs to be declared as async for React to intercept the form's submit event.
  • dThe <form> element needs an explicit action="#" attribute to stay on the same page.
Explanation:A native <form> submits and reloads the page by default when a submit button is clicked, unless something cancels that behavior. Calling e.preventDefault() inside the onSubmit handler stops the browser's default navigation, letting onSearch() run as the only visible effect.
React Forms SuspenseDifficulty 2
function TermsCheckbox() {
  const [accepted, setAccepted] = useState(false);
  return (
    <input
      type="checkbox"
      checked={accepted}
      onChange={e => setAccepted(e.target.value)}
    />
  );
}

After the first click the box stays checked and can never be unchecked. What is the bug?
  • auseState(false) is invalid for a checkbox; it must be initialized with an empty string instead.
  • bCheckboxes cannot be controlled components in React and must always be left uncontrolled.
  • cA checkbox's controlled state is bound with checked/e.target.checked, not value/e.target.value.✓
  • dThe onChange handler must always be renamed to onClick for checkbox and radio input types specifically.
Explanation:A checkbox is controlled with the boolean checked prop and read back from e.target.checked. Here the handler reads e.target.value, which for a checkbox is the fixed submit string ("on" by default) — so after the first click accepted becomes the truthy string "on" and checked={accepted} stays true forever (verified by running it). Reading e.target.checked gives the boolean React actually needs.

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview