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 "You Might Not Need an Effect" that anyone should read before writing their first effect. It's not an opinionated blog post — it's official documentation from the React team. And it says explicitly that using effects to transform data during render is wrong.

The core problem is that useEffect runs after the render. When you use it to derive or sync state from props or existing state, you're forcing an extra cycle: render → effect → setState → render again. That's visual noise, momentary inconsistencies, and a dependency graph that becomes impossible to follow.

Look at this classic pattern I found repeated everywhere:

// ❌ useEffect to derive state — documented antipattern by React
const [items, setItems] = useState<Item[]>([]);
const [filteredItems, setFilteredItems] = useState<Item[]>([]);

useEffect(() => {
  // Every time items changes, we filter
  // This generates an unnecessary extra render
  setFilteredItems(items.filter(item => item.active));
}, [items]);

This effect looks reasonable. It isn't. It generates two renders when one is enough. And if items comes from an async fetch, the intermediate state where filteredItems is stale is completely visible to the user.

The solution is to not have filteredItems as state at all:

// ✅ Derived state — calculated during render, no effect needed
const [items, setItems] = useState<Item[]>([]);

// Recalculated on every render that involves items
// If the calculation is expensive, useMemo is the tool — not useEffect
const filteredItems = items.filter(item => item.active);

If the filter is computationally expensive, useMemo with the right dependency. If it's cheap — and most are — not even that. Just a direct calculation during render.

The 4 concrete categories and what replaces them

1. State derived from props or existing state → calculation in render or useMemo

We already saw this above. The practical rule: if you can calculate something from the state or props you already have, it's not new state. It's a function of what already exists.

// ❌ Version with effect
const [user, setUser] = useState<User | null>(null);
const [displayName, setDisplayName] = useState('');

useEffect(() => {
  setDisplayName(user ? `${user.firstName} ${user.lastName}` : 'Guest');
}, [user]);

// ✅ Correct version: derived inline
const displayName = user ? `${user.firstName} ${user.lastName}` : 'Guest';

Looks trivial. In a real codebase with 30 components doing this, the cumulative impact on re-renders is anything but trivial.

2. Post-event synchronization → direct event handlers

Another pattern I kept finding: an effect that watches a piece of state to "do something when it changes," but that change always comes from a user interaction.

// ❌ useEffect reacting to a change that only ever comes from a click
const [selectedId, setSelectedId] = useState<string | null>(null);

useEffect(() => {
  if (selectedId) {
    analytics.track('item_selected', { id: selectedId });
    loadDetails(selectedId);
  }
}, [selectedId]);

// ✅ The event handler already knows everything it needs to know
const handleSelect = (id: string) => {
  setSelectedId(id);
  // The logic that reacts to the event goes HERE, not in an effect
  analytics.track('item_selected', { id });
  loadDetails(id);
};

The difference isn't just aesthetic. With the effect, any change to selectedId — even a programmatic one, even from another effect — triggers the logic. With the handler, the intent is explicit: this happens when the user selects something. Fewer surprises, more control.

The React docs put it plainly: if something happens because the user did something, it goes in the event handler. If something happens because the component was shown, it goes in an effect. The confusion between these two cases is the root of most useEffect bugs I see.

3. Data fetching → use() with Suspense in React 19, or Server Components

This is the category where React 19 changes the game the most. Fetching with useEffect is the most copy-pasted pattern on the internet and one of the most problematic:

// ❌ The classic useEffect fetch — race conditions waiting to happen
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);

useEffect(() => {
  // Without cleanup, this can set state on an unmounted component
  fetch(`/api/items/${id}`)
    .then(r => r.json())
    .then(setData)
    .finally(() => setLoading(false));
}, [id]);

This code has a classic race condition: if id changes quickly, two fetches run in parallel and the result can arrive in any order. You can mitigate it with cleanup, but that's boilerplate most people skip.

React 19 brings use() which integrates with Suspense:

// ✅ React 19: use() + Suspense — no useEffect, no manual loading state
import { use, Suspense } from 'react';

// The promise is created outside the component or passed as a prop
function ItemDetail({ itemPromise }: { itemPromise: Promise<Item> }) {
  // use() suspends the component until the promise resolves
  const item = use(itemPromise);

  return <div>{item.name}</div>;
}

// In the parent component:
function Page({ id }: { id: string }) {
  // The promise is created here, React manages the lifecycle
  const itemPromise = fetchItem(id); // function that returns Promise<Item>

  return (
    <Suspense fallback={<Skeleton />}>
      <ItemDetail itemPromise={itemPromise} />
    </Suspense>
  );
}

But if you're working with App Router in Next.js 16, the most honest answer is: use Server Components for the fetch. The data arrives serialized to the client, no loading state, no race conditions, no useEffect. For more complex cases where the fetch depends on user interaction, use() with Suspense is the way.

This connects to something I documented in the post about Prisma Server Actions in Next.js 16 — 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 N+1 that shows up when you least expect it in Prisma has the same structure — a pattern that seems reasonable until you look at it with the right question.

Original source:

• React docs — You Might Not Need an Effect: https://react.dev/learn/you-might-not-need-an-effect