{"id":95,"date":"2026-04-17T05:03:21","date_gmt":"2026-04-17T05:03:21","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/?p=95"},"modified":"2026-04-17T05:03:21","modified_gmt":"2026-04-17T05:03:21","slug":"useoptimistic-react-19-hook-i-keep-forgetting","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/useoptimistic-react-19-hook-i-keep-forgetting\/","title":{"rendered":"useOptimistic is the React 19 hook I keep forgetting I have"},"content":{"rendered":"

Short version for the impatient: useOptimistic<\/code> in React 19 lets you show a pretend “done” UI the instant the user clicks, then quietly reconcile with what the server actually says. It’s not magic, it’s not a replacement for proper state management, and I still forget it exists about once a week. If you want the long version and the mistakes I made so you don’t have to, read on.<\/p>\n

I was building a little comment thread feature last Tuesday and caught myself writing the same awkward setPending(true)<\/code> dance I’ve written since 2018. Halfway through, I remembered React 19 shipped with a hook designed exactly for this. I had to go re-read the docs because I kept confusing it with useTransition<\/code>. So this post is the cheat sheet I wish I’d written for myself.<\/p>\n

What useOptimistic actually does<\/h2>\n

The hook gives you a second, temporary copy of your state that you can mutate instantly while an async update is in flight. When the real update resolves (or fails), the optimistic copy gets thrown away and React snaps back to whatever the real state is.<\/p>\n

The API is small:<\/p>\n

const [optimisticState, addOptimistic] = useOptimistic(\n  actualState,\n  (currentState, optimisticValue) => nextState\n);\n<\/code><\/pre>\n
That second argument is a reducer. It’s called with the current optimistic state and whatever value you pass to addOptimistic<\/code>, and you return the new optimistic state. Same shape as useReducer<\/code>, just scoped to the optimistic layer.<\/p>\n
The bit that tripped me up the first time: addOptimistic<\/code> only works inside a transition. If you call it from a plain event handler with no async work around it, React throws. In practice that means you call it right before (or inside) a Server Action or startTransition<\/code> block. The React docs for useOptimistic<\/a> spell this out, but I missed it on first read.<\/p>\n
The before\/after that sold me<\/h2>\n
\"useOptimistic<\/p>\n
Here’s the old way I was writing an optimistic like button. It works, but look at how much ceremony there is for “show the heart as red immediately”:<\/p>\n
\/\/ React 18 way\nfunction LikeButton({ postId, initialLiked, initialCount }) {\n  const [liked, setLiked] = useState(initialLiked);\n  const [count, setCount] = useState(initialCount);\n  const [pending, setPending] = useState(false);\n\n  async function handleClick() {\n    const prevLiked = liked;\n    const prevCount = count;\n    setLiked(!liked);\n    setCount(liked ? count - 1 : count + 1);\n    setPending(true);\n    try {\n      await fetch(`\/api\/like\/${postId}`, { method: 'POST' });\n    } catch (e) {\n      setLiked(prevLiked);\n      setCount(prevCount);\n    } finally {\n      setPending(false);\n    }\n  }\n\n  return <button onClick={handleClick} disabled={pending}>{liked ? '\u2665' : '\u2661'} {count}<\/button>;\n}\n<\/code><\/pre>\n
Three useState<\/code> calls, manual rollback, and I have to remember to snapshot the previous values before I mutate. I got this wrong for two weeks on a side project because I forgot the rollback path on a network error and users saw phantom likes.<\/p>\n
Here’s the same thing with useOptimistic<\/code> and a Server Action:<\/p>\n
\/\/ React 19 way\nimport { useOptimistic } from 'react';\nimport { toggleLike } from '.\/actions';\n\nfunction LikeButton({ postId, liked, count }) {\n  const [optimistic, addOptimistic] = useOptimistic(\n    { liked, count },\n    (state) => ({ liked: !state.liked, count: state.liked ? state.count - 1 : state.count + 1 })\n  );\n\n  async function handleClick() {\n    addOptimistic(null);\n    await toggleLike(postId);\n  }\n\n  return (\n    <form action={handleClick}>\n      <button>{optimistic.liked ? '\u2665' : '\u2661'} {optimistic.count}<\/button>\n    <\/form>\n  );\n}\n<\/code><\/pre>\n
No rollback code. If toggleLike<\/code> throws, React discards the optimistic value and renders whatever the real liked<\/code>\/count<\/code> props are (which come from the server on the next render). The rollback is the absence of a commit.<\/p>\n
That’s the trick worth internalizing: optimistic state isn’t “state you update”. It’s “a derived view of real state plus a pending action”. If the action never commits, the view never changes.<\/p>\n
The task list example, with actual subtleties<\/h2>\n
The canonical example in every tutorial is a task list. I’ll do it too, but I’ll show the bit the tutorials skip: what happens when the user clicks three times in a row.<\/p>\n
function TodoList({ todos, addTodoAction }) {\n  const [optimisticTodos, addOptimisticTodo] = useOptimistic(\n    todos,\n    (current, newTodo) => [...current, { ...newTodo, pending: true }]\n  );\n\n  async function formAction(formData) {\n    const text = formData.get('text');\n    addOptimisticTodo({ id: crypto.randomUUID(), text });\n    await addTodoAction(text);\n  }\n\n  return (\n    <>\n      <form action={formAction}>\n        <input name="text" \/>\n        <button>Add<\/button>\n      <\/form>\n      <ul>\n        {optimisticTodos.map((t) => (\n          <li key={t.id} style={{ opacity: t.pending ? 0.5 : 1 }}>{t.text}<\/li>\n        ))}\n      <\/ul>\n    <\/>\n  );\n}\n<\/code><\/pre>\n
If the user smashes the Add button three times quickly, you get three concurrent Server Action calls. React queues the optimistic updates: each one is applied on top of the current optimistic state, in call order. When the first server response comes back, React re-runs the reducer from the new todos<\/code> base with the remaining in-flight updates layered on top. You don’t have to manage this. It’s genuinely one of the nicer things about the design.<\/p>\n
What you do have to manage is keys. If you generate IDs on the client (crypto.randomUUID()<\/code>), the server’s response will come back with a different ID, and React will unmount and remount the <li><\/code>. That’s a wasted render and it’ll kill any CSS transitions you had on the row. Either have the server accept client-generated IDs, or use a separate client-only key for the pending row.<\/p>\n
Where it doesn’t fit<\/h2>\n
I keep seeing people reach for useOptimistic<\/code> when they should be using local state or useTransition<\/code>. A few honest warnings:<\/p>\n