I spent an embarrassing amount of time last month deleting code I was proud of.<\/p>\n
It was a login form. Nothing fancy. Email, password, a submit button, and the usual pile of state bolted around it: a Then I actually sat down with React 19’s So this is the before and after, plus the parts where the new hooks genuinely annoyed me, because they aren’t free. If you’ve been avoiding React 19 because the upgrade notes looked like a weekend you didn’t have, the forms story alone might earn back the afternoon.<\/p>\n Here’s the React 18 version, more or less how I wrote it for years. Four pieces of state, a handler that has to remember to flip Look at how much of this has nothing to do with logging in. Two controlled inputs that exist only to shuttle characters into state. A The controlled-input dance is the part that always bothered me most. React can already read form values straight off the DOM through Same form, React 19. The whole thing collapses into one hook call.<\/p>\n A few things happened here that are worth saying out loud. The inputs are uncontrolled now. They just have a And the return value of the action becomes the new state. Return The signature reads a little strange the first time. The action gets The other thing that took me a beat: because the returned value is your state, you get to decide its shape. In the login form I return a plain string. In a signup form I return an object with per-field errors, so I can render a message under the specific input that failed. React doesn’t care what you return, it just hands it back on the next render. That flexibility is easy to miss when every tutorial returns a string and moves on.<\/p>\n If you want the full picture of why React 19 leaned this way, the React 19 release post<\/a> is the primary source, and it’s one of the better-written release notes I’ve read.<\/p>\n There’s a second hook that pairs with this, and it solves an annoyance I’d just learned to live with: the submit button usually lives a few components away from the form’s state, so wiring Drop I don’t want to oversell this. A few things cost me time.<\/p>\n Client-side validation gets a bit awkward. With controlled inputs I used to validate on every keystroke. With uncontrolled fields the values live in the DOM until submit, so instant “passwords don’t match” feedback needs a different approach, usually native HTML validation or reading Actions also swallow errors by design. If your action throws instead of returning, the error bubbles to the nearest error boundary rather than into your And honestly, So no, I’m not deleting Pick your ugliest form. The one with five pieces of state and a handler you’ve been afraid to touch. Rewrite just that one with Don’t do a big-bang migration. React 19 lets these hooks sit next to your old controlled forms with no drama, so convert one, ship it, and get a feel for the pending and error flow before you commit. For me it took exactly one real form to stop writing the old pattern by hand. My guess is it’ll take you about the same.<\/p>\n","protected":false},"excerpt":{"rendered":" React 19’s useActionState and useFormStatus let me delete the loading flags, error state, and controlled inputs I hand-wrote in every form. Before and after code.<\/p>\n","protected":false},"author":2,"featured_media":507,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"React 19's useActionState and useFormStatus let me delete the loading flags, error state, and controlled inputs I hand-wrote in every form. Before and after code.","rank_math_focus_keyword":"react useactionstate","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[354],"tags":[229,38,41,359,136],"class_list":["post-508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-react","tag-forms","tag-frontend","tag-react","tag-react-19-2","tag-useactionstate"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=508"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/508\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/507"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}loading<\/code> boolean, an error<\/code> string, and a submit handler I’d rather not show my past self. I’ve written that exact pattern maybe forty times across different projects. It’s muscle memory now, which is the problem. I stopped noticing how much of it was busywork.<\/p>\nuseActionState<\/code> and useFormStatus<\/code>, and roughly two thirds of that form evaporated. Not refactored into a hook I’d have to maintain. Gone. The bookkeeping I’d been hand-rolling since 2019 is now the framework’s job.<\/p>\nThe form state I used to write by hand<\/h2>\n
loading<\/code> on and off in the right order, and a try\/catch\/finally<\/code> that I have copy-pasted so many times I could type it asleep.<\/p>\nfunction LoginForm() {\n const [email, setEmail] = useState("");\n const [password, setPassword] = useState("");\n const [loading, setLoading] = useState(false);\n const [error, setError] = useState(null);\n\n async function handleSubmit(e) {\n e.preventDefault();\n setLoading(true);\n setError(null);\n try {\n await login({ email, password });\n } catch (err) {\n setError(err.message);\n } finally {\n setLoading(false);\n }\n }\n\n return (\n <form onSubmit={handleSubmit}>\n <input value={email} onChange={(e) => setEmail(e.target.value)} \/>\n <input\n type="password"\n value={password}\n onChange={(e) => setPassword(e.target.value)}\n \/>\n {error && <p className="error">{error}<\/p>}\n <button disabled={loading}>\n {loading ? "Signing in..." : "Sign in"}\n <\/button>\n <\/form>\n );\n}\n<\/code><\/pre>\nfinally<\/code> block whose entire job is to undo a thing I did three lines earlier. And the classic bug hiding in plain sight: forget to reset error<\/code> at the top of the handler, and a stale message sticks around from the last failed attempt. I’ve shipped that bug. More than once.<\/p>\nFormData<\/code>. But for years the idiomatic answer was to mirror every field into useState<\/code> anyway, so you ended up maintaining a second copy of data the browser was already tracking for you.<\/p>\nWhat useActionState actually gives you<\/h2>\n
import { useActionState } from "react";\n\nfunction LoginForm() {\n const [error, submitAction, isPending] = useActionState(\n async (previousState, formData) => {\n try {\n await login({\n email: formData.get("email"),\n password: formData.get("password"),\n });\n return null;\n } catch (err) {\n return err.message;\n }\n },\n null,\n );\n\n return (\n <form action={submitAction}>\n <input name="email" \/>\n <input name="password" type="password" \/>\n {error && <p className="error">{error}<\/p>}\n <button disabled={isPending}>\n {isPending ? "Signing in..." : "Sign in"}\n <\/button>\n <\/form>\n );\n}\n<\/code><\/pre>\nname<\/code>, and the values arrive as formData<\/code> when the form submits. No value<\/code>, no onChange<\/code>, no mirrored state.<\/p>\nisPending<\/code> is handed to me. I never set it, never reset it, can’t forget the finally<\/code>. React flips it while the action runs and flips it back when the action resolves. That’s the whole loading<\/code> boolean, deleted.<\/p>\nerr.message<\/code> and it lands in error<\/code>. Return null<\/code> and the error clears. The stale-error bug I mentioned can’t happen, because every submit produces a fresh state instead of me mutating the old one. The React team’s own useActionState reference<\/a> frames it as state that’s derived from the last submission, and once that clicked for me the whole thing felt obvious.<\/p>\npreviousState<\/code> as its first argument before formData<\/code>. I ignored it in the login example, but it’s genuinely useful. Think of a “retry” counter, or a wizard where each step needs to see what the last step returned. It’s useReducer<\/code> energy, except the dispatch is a form submission.<\/p>\nuseFormStatus, or how the button knows it’s busy<\/h2>\n
pending<\/code> down to it meant prop-drilling or context.<\/p>\nuseFormStatus<\/code> reads the status of the nearest parent <form><\/code> directly. No props.<\/p>\nimport { useFormStatus } from "react-dom";\n\nfunction SubmitButton() {\n const { pending } = useFormStatus();\n return (\n <button disabled={pending}>\n {pending ? "Signing in..." : "Sign in"}\n <\/button>\n );\n}\n<\/code><\/pre>\n<SubmitButton \/><\/code> anywhere inside the form and it knows when the form is submitting. That’s it. The one rule that tripped me up: it has to be a child component. Call useFormStatus<\/code> in the same component that renders the <form><\/code> and you get pending: false<\/code> forever, because it looks upward for a form and there isn’t one above it yet. The useFormStatus docs<\/a> say this plainly, and I still ignored it for a good twenty minutes before rereading.<\/p>\nWhere it bit me, and where I still reach for useState<\/h2>\n
FormData<\/code> in an onChange<\/code> on the form. Not hard, just different, and I fought it before I accepted it.<\/p>\nerror<\/code> state. That’s fine if you’ve got boundaries set up, which is a habit I’d recommend anyway. I wrote about the ones I actually ship over in my work on frontend reliability<\/a> if you want the setup.<\/p>\nuseActionState<\/code> isn’t the answer for everything. A search box that filters a list as you type is still a useState<\/code> job. Actions shine when there’s a discrete submit with a pending window and a result. For live-as-you-type UI, the optimistic-update route fits better, which is exactly the case I made in the post on useOptimistic<\/a>. Different tool, different problem.<\/p>\nuseState<\/code>. I’m deleting the specific, repetitive version of it that every form used to demand.<\/p>\nWhat I’d actually do this week<\/h2>\n
useActionState<\/code>, move the submit button into its own child component with useFormStatus<\/code>, and see how much code disappears.<\/p>\n