Why I Stopped Using useEffect to Sync State — and What I Use Instead

I made a mistake that, I suspect, most teams working with React are still making today: I used useEffect as a general-purpose state synchronization tool. If something changed and I wanted to react to it, there was the effect. Clean, familiar, and — I figured this out way too late — completely wrong for most of those cases.

I'm not telling you this to flagellate myself. I'm telling you because when I systematically audited the effects in a React 19 codebase, I found exactly four categories of misuse repeated over and over. Each one has a better solution. And none of the four requires hacks or external libraries.

My thesis: useEffect isn't broken. What's broken is the mental model we teach alongside it — as if it were the natural place to "do things when something changes." React 19 puts better tools closer to the surface, but you still need the judgment to choose between them. Without that, React 19 just gives you new places to put the same old problems.

useEffect for state synchronization: the antipattern nobody names

The official React documentation has an entire page called — the boundary between what runs on the server and what runs on the client significantly shifts which patterns actually make sense.

4. Post-submit transformations → Server Actions

The last category: the effect that listens to the result of a submit to update derived state, show messages, or redirect.

// ❌ useEffect watching the result of a submit

const [submitResult, setSubmitResult] = useState<Result | null>(null);

const [errorMessage, setErrorMessage] = useState('');



useEffect(() => {

  if (submitResult?.error) {

    setErrorMessage(submitResult.error.message);

  }

}, [submitResult]);

With Server Actions in React 19 and the useActionState hook (previously useFormState), this collapses into a much more direct pattern:

// ✅ useActionState — form state and action result, integrated

import { useActionState } from 'react';



async function submitForm(prevState: State, formData: FormData): Promise<State> {

  'use server';

  // The action runs on the server, returns the new state

  const result = await processForm(formData);

  if (!result.ok) {

    return { error: result.message };

  }

  return { success: true };

}



function MyForm() {

  const [state, action, isPending] = useActionState(submitForm, { error: null });



  return (

    <form action={action}>

      {/* No useEffect, no extra state, no manual synchronization */}

      {state.error && <p className="error">{state.error}</p>}

      <button disabled={isPending}>Save</button>

    </form>

  );

}

Form state, error feedback, and loading are all integrated without a single useEffect. It's not magic — it's that the responsibility is in the right place.

The errors that persist and the ones that disappear

There are cases where useEffect is the right tool: subscriptions to external stores, synchronization with DOM APIs you don't control (a third-party map, a canvas library), or setup/teardown of resources that exist outside of React's model.

What disappears with these patterns:

• 
  Race conditions in fetch — use() and Server Components eliminate them structurally


• 
  Inconsistent intermediate renders — derived state has no inconsistent state because it isn't state


• 
  Chained effect graphs — when one effect sets state that fires another effect, debugging is hell. Event handlers cut that off at the root


• 
  Forgotten cleanup — if there's no effect, there's no cleanup to forget

What doesn't disappear:

• 
  Thinking about dependencies — useMemo also has a dependency array. use() requires understanding how React handles promises. The judgment is still necessary.


• 
  Suspense complexity — badly placed boundaries break UX in non-obvious ways. It's not an automatic replacement.

FAQ

Did useEffect become obsolete in React 19?

No. The React team didn't deprecate it or mark it as legacy. What changed is that React 19 puts better tools within reach for the cases where useEffect was previously the only available option. For subscriptions, integration with external DOM APIs, and synchronization with systems outside of React's model, useEffect is still correct.

Does use() replace useEffect for all fetches?

For fetches in client components that depend on user interaction, use() with Suspense is a concrete alternative. For initial data fetches in App Router, Server Components are the most direct answer — neither use() nor useEffect. The choice depends on whether the data can be resolved on the server or needs to wait for the client.

When to use useMemo vs direct calculation for derived state?

Direct calculation first. useMemo only when the calculation is measurably expensive (sort/filter over large arrays, complex transformations) and the profiler confirms there's an actual problem. Adding useMemo preemptively is just another form of over-engineering — it has a readability cost and the dependencies can also be wrong.

Does useActionState work without Server Actions?

Yes. useActionState accepts any async function, not just Server Actions. If you prefer to handle the submit on the client side, you can pass it a client-side function. The integration with Server Actions is the cleanest in Next.js with App Router, but it's not a requirement.

How do I migrate an existing codebase? Is there an incremental path?

The safest path is by category, not by file. Start by identifying all the useEffect calls that only derive state — they're the safest to migrate and give the most immediate benefit. Then the ones that react to user events. Fetches last, because they require decisions about Suspense boundaries that affect UX.

Do these patterns change if I'm using Zustand, Jotai, or Redux?

Partially. External stores solve the global state problem, but the antipattern of deriving state inside a component with useEffect shows up just the same. The question "can I calculate this during render?" applies regardless of which state management system you're using.

The judgment that doesn't come from the framework

What frustrated me most when I audited this codebase wasn't finding the antipatterns — that was expected. It was realizing they were there because at the time nobody had a clear rule for deciding when to use useEffect. We used it as the default tool for "do something when something changes," and that mental model is wrong from the start.

React 19 makes it easier to do the right thing: use() exists, useActionState exists, Server Components are more integrated. But without the judgment of when each tool applies, what happens is that the same problems just migrate to the new APIs.

My concrete take: before writing a useEffect, ask yourself whether what you want to do is (a) calculate something from existing state, (b) react to a user action, (c) load data, or (d) sync with something external to React. Only the last case justifies an effect. The first three have better solutions in React 19, and the official React documentation says so explicitly.

If you're auditing a codebase and don't know where to start, the same audit exercise applies to other patterns: the