Skip to content
TaeyoungKim.dev

Cannot Type into a React Input? Check value and onChange

WebWritten 3 min readTaeyoungKim
LinkedInX

The input is visible, but letters vanish as soon as you type them. With <input value={keyword} />, React tries to keep the displayed value equal to keyword. If typing never updates that state, the next render restores the old value. The missing piece is who owns the input value, not a broken keyboard control.

With value, React state is the source of truth

The diagram forms a loop: input → onChange → state → value. Connecting value without updating state breaks the loop, so typed text does not persist on screen.

A controlled input keeps its current value in state and updates that state when the user types. Here, the field and preview both read keyword:

jsx
import { useState } from 'react';

export default function SearchDraft() {
  const [keyword, setKeyword] = useState('');

  return (
    <section>
      <label htmlFor="keyword">Search term</label>
      <input
        id="keyword"
        name="keyword"
        value={keyword}
        onChange={(event) => setKeyword(event.target.value)}
      />
      <p>Preview: {keyword || 'Nothing entered'}</p>
      <button type="button" onClick={() => setKeyword('')}>
        Clear
      </button>
    </section>
  );
}

On each edit, onChange reads the current text and setKeyword updates state. The next render receives the new value. Clear sets the same state to an empty string, so both field and preview clear together. type="button" also prevents this button from submitting a form if the component is later placed inside one.

What changes if value is present but the update is missing or delayed?

Without onChange, typed text is never recorded in state. Similar symptoms arise if the handler delays the update or replaces it with an older value. Compare the event's event.target.value with the value actually passed to setKeyword at the same point in time.

If the intention is only to show an initial value and then let the browser own the field, defaultValue may be appropriate instead. Changing React state alone will not necessarily change an uncontrolled field afterward. Decide whether typing, validation, and clearing all need to follow one state value, and avoid switching one input between controlled and uncontrolled modes. The React input reference explains this boundary.

How should you test behavior and performance?

Type one character at a time and confirm it stays visible. Then paste, delete everything, and click Clear; verify the field and preview agree. If a value starts as an empty string but becomes undefined after a server response, inspect initialization and response normalization because control mode can change.

A controlled input updates state for every edit. If one field causes a heavy page to recompute, move its state into a smaller component or separate expensive calculations. Skipping state updates to hide a performance problem brings back the disappearing-text bug. Text held in UI state is not automatically validated or authorized for server submission; check those concerns at the boundary too.

Key takeaways: value and onChange work together

If value controls an input, update state from the user's new text in onChange. If you only need an initial value, consider defaultValue. When text disappears, inspect when state changes and what value it receives before changing the input element itself.

Author

TaeyoungKim

Connecting technical foundations with implementation, verification, and production decisions.

#React#input#value#onChange#controlled input

Read next