DEV Community: Vitalii

useOptimistic + useActionState: React 19 Killed 50 Lines of My Boilerplate

Vitalii — Sun, 28 Jun 2026 13:43:12 +0000

Every form submission in React used to look like this:

const [data, setData] = useState(null)
const [loading, setLoading] = useState(false)
const [error, setError] = useState(null)

async function handleSubmit(e) {
  e.preventDefault()
  setLoading(true)
  try {
    const result = await submitToServer(formData)
    setData(result)
  } catch (err) {
    setError(err.message)
  } finally {
    setLoading(false)
  }
}

Three useState calls. A try/catch/finally. Manual loading and error flags. And that's without optimistic updates — add those and you're looking at another 20 lines of snapshot/revert logic.

React 19 ships two hooks that delete most of this.

`useActionState` — form lifecycle in one hook

const [error, submitAction, isPending] = useActionState(
  async (prevState, formData) => {
    const res = await fetch('/api/submit', {
      method: 'POST',
      body: formData,
    })
    if (!res.ok) return 'Something went wrong'
    return null
  },
  null
)

return (
  <form action={submitAction}>
    <input name="email" type="email" />
    <button disabled={isPending}>
      {isPending ? 'Sending...' : 'Submit'}
    </button>
    {error && <p>{error}</p>}
  </form>
)

isPending is automatic. Error state is the return value of your action. No useState, no try/catch wrappers, no finally.

`useOptimistic` — instant UI without manual rollback

The old way of doing a like button:

// snapshot → update → revert on error = ~30 lines

The React 19 way:

const [optimisticLikes, addOptimisticLike] = useOptimistic(
  likes,
  (current, increment) => current + increment
)

async function handleLike() {
  addOptimisticLike(1)      // instant UI
  await likePost(postId)    // server confirms
}

return <button onClick={handleLike}>❤️ {optimisticLikes}</button>

That's it. If the server call fails, React automatically reverts to the real value — no manual rollback code needed. The optimistic state is just a temporary layer that disappears when the action settles.

One important gotcha

addOptimistic must be called before any await in your action. React's transition system only captures optimistic updates issued synchronously before the first suspension point. Call it after an await and the update won't show up.

// ✅ correct
addOptimisticLike(1)
await likePost(postId)

// ❌ won't work
await someOtherThing()
addOptimisticLike(1)

When to still use React Query / SWR

These hooks are for component-local action state. If your mutation needs to invalidate a cache shared across multiple components, you still want React Query or similar. But for the submit-and-respond pattern that covers the majority of forms and mutations in a typical app — these built-ins are now the right default.

5 React Server Components Mistakes I See in Almost Every Codebase

Vitalii — Sun, 28 Jun 2026 13:37:21 +0000

React Server Components are now the default in Next.js. Most teams have adopted them. Most teams are also making the same handful of mistakes.

I've been working with RSC in production for a while now, and these five patterns show up constantly.

1. Putting `use client` too high in the tree

The most common one. You hit an error, add use client to the nearest component, and move on. Works — but now you've pulled an entire subtree out of server rendering.

// ❌ One button click handler sends 200 lines to the client
'use client'
export function DashboardSection() { ... }

// ✅ Push it to the leaf
export function DashboardSection() {
  return (
    <div>
      <StatsTable />     {/* stays on server */}
      <RestockButton />  {/* 'use client' lives here */}
    </div>
  )
}

Rule of thumb: use client belongs on the smallest component that actually needs interactivity.

2. Sequential awaits when data is independent

This one silently kills your TTFB. If your data sources don't depend on each other, don't fetch them one by one:

// ❌ Total time = 50ms + 200ms + 100ms = 350ms
const user = await getUser()
const stats = await getStats()
const activity = await getActivity()

// ✅ Total time = max(200ms) = 200ms
const [user, stats, activity] = await Promise.all([
  getUser(), getStats(), getActivity()
])

A 2x perf win with one line change.

3. Blocking the entire page on slow data

One slow API call with no Suspense boundary = your user stares at nothing until everything resolves. You've just built SSR circa 2015.

// ✅ Shell renders immediately, analytics loads progressively
export default function Home() {
  return (
    <div>
      <Header />
      <Suspense fallback={<AnalyticsSkeleton />}>
        <AnalyticsWidget />
      </Suspense>
    </div>
  )
}

Move slow, non-critical data behind Suspense. The rest of the page streams instantly.

4. The "popcorn effect" from too many boundaries

The opposite problem. When every small element has its own Suspense boundary, the page fills up with rapid-fire skeleton → content transitions. It feels broken even though technically everything loaded fine.

Group related UI into a single boundary. Users should perceive one coherent loading state per logical section, not 12 independent ones.

5. Not knowing about the RSC security CVEs

Last December, the React team disclosed a series of serious vulnerabilities in RSC (DoS and source code exposure). An incomplete fix led to follow-up CVEs through January 2026.

If you're on React 19, check your version:

Safe: 19.0.4, 19.1.5, 19.2.4 and above
Everything before that is vulnerable

Run npm ls react and update if needed. If your app doesn't use a server, you're not affected.

RSC is genuinely great once you internalize the server/client boundary model. The mental shift is real, but so are the performance gains — real apps see 30–60% smaller JS bundles after proper adoption.

What's the trickiest RSC issue you've hit in production?

AI Won't Replace React Developers — But It's Changing How We Think

Vitalii — Sun, 28 Jun 2026 13:33:37 +0000

There's a hot take circulating in dev circles: "AI will replace frontend developers."

After shipping React apps daily alongside AI tools, here's what I actually observe: AI is changing how we write React — not what we build with it.

What AI handles well

Boilerplate: hooks, utility components, typed props interfaces
Repetitive patterns: form handlers, API wrappers, test scaffolding
Refactoring: "extract this into a custom hook" just works now
Documentation lookup: no more switching tabs to check React Query's staleTime options

Tools like Cursor, Claude Code, and Copilot with MCP integrations can now read your entire codebase and generate components that match your existing patterns. That's genuinely useful.

What still requires a human

Here's where it breaks down. AI can generate a Server Component — but it can't decide when you should use one. It can scaffold Zustand stores, but it won't tell you whether you actually need global state or just better component composition.

The real architectural questions:

Should this data be fetched on the server or the client?
Is this a state management problem or a colocation problem?
Will this abstraction make the next developer's life easier or harder?

These aren't autocomplete problems. They require understanding your users, your team's skill level, and your system's constraints.

The shift I'm actually seeing

Junior devs using AI as a crutch are shipping faster but debugging slower — because they don't understand the code they're merging. Senior devs using AI as a force multiplier are the ones pulling away from the pack.

The mental model I've landed on: AI is a very fast junior who never sleeps. You still need to review the PR.

What this means for 2026

The bar for "good React developer" isn't getting lower — it's shifting. Less time on syntax, more time on architecture, performance tradeoffs, and knowing why something is slow, not just running Lighthouse and hoping.

If you're learning React right now: understand the fundamentals deeply before leaning on AI. If you're senior: use it aggressively for execution, but keep the thinking to yourself.

Curious what you're seeing in your teams — is AI actually changing how you approach component architecture, or just helping you type faster?