In a React form built from uncontrolled inputs, how do you read the field values when the user submits — with refs or with FormData?

## The premise: the DOM already knows An uncontrolled input holds its own value. Nothing in React state mirrors it, so "reading the form" means asking the DOM, at the moment you actually need the answer — normally when the user submits. ## Reading one field with a ref ```jsx function Search() { const queryRef = useRef(null); function handleSubmit(e) { e.preventDefault(); console.log(queryRef.current.value); } return ( <form onSubmit={handleSubmit}> <input ref={queryRef} defaultValue="" /> <button type="submit">Go</button> </form> ); } ``` `queryRef.current` is the real `HTMLInputElement`, so everything the DOM offers is available: `.value` for text, `.checked` for a checkbox or radio, `.files` for a file input, `.select()` and `.focus()` for interaction. The timing rule matters. React attaches the node during commit, so `ref.current` is `null` on the first render and becomes the element afterwards. Read it from event handlers or effects; reading it during render is both null-prone and a render-purity violation. Detaching cleans up too: when the element unmounts, React sets `current` back to `null`. Refs scale badly. Ten fields means ten refs to declare, thread and keep in sync with the markup — at which point you are hand-rolling what the platform already does. ## Reading the whole form with FormData ```jsx function handleSubmit(e) { e.preventDefault(); const data = new FormData(e.currentTarget); const email = data.get('email'); // string | File | null const tags = data.getAll('tag'); // every control named "tag" const all = Object.fromEntries(data); // plain object, last value wins } ``` `FormData` walks the form's controls exactly as a native submission would. Note `e.currentTarget`, not `e.target`: `currentTarget` is the `<form>` the handler is attached to, while `target` is whatever element originated the event — usually the same here, but not something to rely on. What goes in is decided by the `name` attribute. An input with only an `id`, a `ref`, or a React `key` contributes nothing. That single rule accounts for most "my FormData is empty" confusion. ## What FormData includes, and what it quietly leaves out - **Disabled controls are omitted entirely.** A field disabled while a request is in flight is missing from the payload, not blank. - **Unchecked checkboxes are absent**, not `false`. Test with `data.has('optIn')`, and remember that a ticked checkbox with no explicit `value` attribute submits the string `"on"`. - **Radio groups contribute one entry** — the selected member of the group, under the shared name. - **Repeated names** all appear. `data.get()` returns the first; `getAll()` returns every one; `Object.fromEntries` keeps only the last, which silently loses data on multi-value fields. - **File inputs yield `File` objects**, not strings, so the same `get()` call returns a different type. - **Submit buttons are not included** by plain `new FormData(form)`; you pass the button as the constructor's second argument if you need to know which one submitted. Because values arrive as strings, numbers and booleans need converting at the boundary — `Number(data.get('quantity'))` — which is exactly the seam where a schema validator earns its place. ## Choosing between them Use a **ref** for one or two fields, or when you also need imperative access (focus the first invalid field, select the text, read `.files`). Use **FormData** for a form of any real size: no per-field wiring, the field list is the markup, and adding an input costs one `name` attribute. Mixed forms are normal — a controlled field or two for live feedback, the rest read from `FormData` at submit. ## A React 19 note In React 19 you can pass a function to a form's `action` prop, and React calls it with the same `FormData` object, no submit handler and no `preventDefault` needed. The mechanics of reading fields are identical; only the plumbing that delivers the object differs.