Okay, quick story. About four months ago I shipped a comments feature for a client dashboard. User clicks Post, we send it to the server, wait for the round-trip, then render the comment. Standard stuff. And every single test user asked me the same thing during the walkthrough: “Is it broken? Why is it lagging?”<\/p>\n
It wasn’t lagging. The round-trip was around 180ms. But 180ms of nothing happening felt slower than 800ms of something happening. So I did what everyone does. I built the optimistic update by hand. Rendered the pending comment with a fake ID, stashed the original state in a ref, wrote rollback logic for the failure case, prayed the state stayed in sync when a user posted three comments in a row.<\/p>\n
That code lived for two weeks. Then I ripped it out and used The signature reads like You pass the real state and a reducer that describes the temporary update. React shows The catch: it only works inside a transition. That means a form action, a call from Here is roughly what my hand-rolled comment poster looked like. Cleaner than the original, still ugly.<\/p>\n Every optimistic feature I built looked like this. A snapshot, a temp record, a swap on success, a revert on failure, a pending flag for the spinner. Multiply by five components in the same app and I had roughly 150 lines of “not real business logic” I was maintaining. The reverts were the worst part. If the user acted again before the first request resolved, the snapshot was stale and the rollback would erase the second comment too.<\/p>\n Here is the same feature with Notice what is gone: no The rollback happens for free. If The one code-review complaint I got: no visible loading feedback on outright failure. Fixed with a try\/catch inside the action that fires a toast on error. React still handles the state part.<\/p>\n Three real cases from the last few months, roughly in order of how much time each one saved me.<\/p>\n Toggle switches on a settings page.<\/strong> Users flip a switch, we PATCH the setting, then re-render from the returned config. Old code had a race where fast toggling would flip back and forth as older responses landed after newer ones. “Mark as read” on a notification list.<\/strong> A user inbox with 40 notifications. Old code updated local state, then swapped after the batch mutation. Ugly loading skeleton whenever they marked 10 at once. Delete-with-undo.<\/strong> This is the sneaky win. When I If you want more of the framework side of this, I wrote about the Next.js server actions pattern I actually ship<\/a> a few weeks back. Only inside a transition.<\/strong> I called The reducer runs on every render during the transition.<\/strong> If your reducer allocates a big array, you allocate it repeatedly. I moved a Server state must be authoritative.<\/strong> I tried once to use It does not deduplicate.<\/strong> If you TypeScript inference is picky.<\/strong> The reducer’s Two cases where I stick with a plain pattern instead.<\/p>\n If the mutation is fire-and-forget and doesn’t affect a visible list, If I need the optimistic-looking state to last longer than the transition, I still use I also don’t use it in server components. It’s a client-only hook, and if you try, the build fails with a clear error. Not a real gotcha, just worth knowing before you refactor.<\/p>\n If there is any place in your app where the user clicks something and then waits, take 20 minutes to try this:<\/p>\n If it feels good, migrate one component at a time. That is how I did it. A month later, the How I replaced hand-rolled optimistic UI code with React 19’s useOptimistic hook. Real patterns, gotchas from two weeks of production, and when to skip it.<\/p>\n","protected":false},"author":2,"featured_media":460,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"How I replaced hand-rolled optimistic UI code with React 19's useOptimistic hook. Real patterns, gotchas from two weeks of production, and when to skip it.","rank_math_focus_keyword":"useoptimistic","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[138,354],"tags":[38,44,382,41,359,355,170,63,68],"class_list":["post-461","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-frontend","category-react","tag-frontend","tag-javascript","tag-optimistic-ui-2","tag-react","tag-react-19-2","tag-react-hooks-2","tag-server-actions-2","tag-typescript","tag-useoptimistic"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/461","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=461"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/461\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/460"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=461"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=461"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=461"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}useOptimistic<\/code>. If you’re still hand-rolling optimistic updates in a React 19 app, this is the post I wish someone had shoved at me back in March.<\/p>\nWhat useOptimistic actually does<\/h2>\n
useOptimistic<\/code> shipped as part of the React 19 release<\/a> and lets you show a temporary state during an async action, then automatically snap back to the real state when that action resolves. That’s it. No state machine. No rollback code. The docs are pretty terse, so read them first<\/a> if you want the primary source.<\/p>\nuseState<\/code> with an extra reducer:<\/p>\nconst [optimistic, addOptimistic] = useOptimistic(\n state,\n (currentOptimistic, action) => nextOptimistic\n);\n<\/code><\/pre>\noptimistic<\/code> while an action is pending, and swaps back to state<\/code> when the transition finishes.<\/p>\nuseActionState<\/code>, or an explicit startTransition(() => ...)<\/code>. Call addOptimistic<\/code> outside a transition and React logs a warning and does nothing. This tripped me up for a full afternoon.<\/p>\nThe before code I’d rather forget<\/h2>\n
function CommentBox({ postId }) {\n const [comments, setComments] = useState([]);\n const [pending, setPending] = useState(null);\n\n async function submit(text) {\n const tempId = crypto.randomUUID();\n const snapshot = comments;\n setPending({ id: tempId, text, status: 'sending' });\n setComments([...comments, { id: tempId, text }]);\n try {\n const saved = await postComment(postId, text);\n setComments((c) =>\n c.map((x) => (x.id === tempId ? saved : x))\n );\n } catch (err) {\n setComments(snapshot);\n toast.error('Comment failed');\n } finally {\n setPending(null);\n }\n }\n \/\/ ...\n}\n<\/code><\/pre>\nThe after with useOptimistic<\/h2>\n
useOptimistic<\/code> and a Next.js server action. I dropped the snapshot logic, the pending flag, and the manual swap.<\/p>\n'use client';\n\nimport { useOptimistic } from 'react';\nimport { postComment } from '.\/actions';\n\nexport function CommentBox({ postId, comments }) {\n const [optimistic, addOptimistic] = useOptimistic(\n comments,\n (state, newComment) => [\n ...state,\n { ...newComment, pending: true },\n ]\n );\n\n async function action(formData) {\n const text = formData.get('text');\n addOptimistic({ id: crypto.randomUUID(), text });\n await postComment(postId, text);\n }\n\n return (\n <form action={action}>\n <ul>\n {optimistic.map((c) => (\n <li key={c.id} className={c.pending ? 'opacity-50' : ''}>\n {c.text}\n <\/li>\n ))}\n <\/ul>\n <input name="text" \/>\n <button>Post<\/button>\n <\/form>\n );\n}\n<\/code><\/pre>\nuseState<\/code> for the list, no snapshot, no rollback branch, no pending flag as separate state. The pending: true<\/code> marker lives inside the optimistic entry, so I can style pending items differently without a parallel data structure.<\/p>\npostComment<\/code> throws, the transition fails and React drops the optimistic entry. If the user posts three comments back to back, each queues into its own transition and resolves independently. No stale-snapshot bug because there’s no snapshot to be stale.<\/p>\nWhere useOptimistic quietly saved me<\/h2>\n
useOptimistic<\/code> serializes the optimistic view through the transition queue, so the last click wins visually and the server response reconciles cleanly.<\/p>\nuseOptimistic<\/code> marks them instantly, keeps them styled as “just read” until the request finishes, then lets the server version take over without a flash.<\/p>\naddOptimistic({ deleted: true })<\/code> and render deleted items with a strikethrough and an Undo button, if the user hits Undo before the transition resolves, I can cancel the pending action and the optimistic state clears itself. No manual “did the undo happen before the delete” bookkeeping.<\/p>\nuseOptimistic<\/code> pairs with server actions the way React Query pairs with fetch.<\/p>\nGotchas I hit in the first two weeks<\/h2>\n
addOptimistic<\/code> from a plain button click handler and React silently ignored it. Half an hour of “why is nothing rendering” before I read the fine print. You need a form action<\/code>, useActionState<\/code>, or an explicit startTransition(() => ...)<\/code> wrapper.<\/p>\n.map<\/code> over the full list into the reducer once and burned a few frames on a large table. Keep the reducer O(k) where k is the size of your update, not the size of the whole list.<\/p>\nuseOptimistic<\/code> as a local-only “pretend it saved” hack for a form without any real server behind it. Don’t. When the transition finishes and the passed-in state<\/code> hasn’t changed, React drops the optimistic update and your UI reverts. Use useState<\/code> for local-only, not this hook.<\/p>\naddOptimistic<\/code> twice for the same logical action, you’ll see two entries. I now generate the temp id from a stable key when I need dedupe.<\/p>\naction<\/code> parameter defaults to the state type, which is almost never what you want. I annotate it explicitly:<\/p>\nuseOptimistic<Comment[], NewComment>(comments, (state, action) => [\n ...state,\n { ...action, pending: true },\n]);\n<\/code><\/pre>\nWhen I still don’t reach for it<\/h2>\n
useOptimistic<\/code> is overkill. A regular useTransition<\/code> with a pending<\/code> flag is smaller and reads better.<\/p>\nuseState<\/code>. useOptimistic<\/code> snaps back the second the transition resolves. That is exactly what you want most of the time and exactly what you don’t want when the flow is “show the new item highlighted for three seconds after save completes”. For that, I keep useState<\/code> for the highlight and let useOptimistic<\/code> handle only the placeholder.<\/p>\nTry this Monday<\/h2>\n
\n
startTransition<\/code>.<\/li>\nuseOptimistic<\/code> and a reducer that appends a pending marker.<\/li>\nuseState + snapshot + rollback<\/code> pattern was gone from the codebase and the loading-spinner tickets stopped showing up in QA. The companion piece on the React 19 use hook I now reach for<\/a> sits next to this one if you want more of the same. And if this “here is what I actually ship” tone is useful, more of it lives at my portfolio and blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"