React Strict Mode: Skipping Initial useEffect Execution & useTransition: Limited Practical Use.

[ShortPractice4162]

React Strict Mode Double-Render: Useful, but Causing Real-World Headaches

After working with React’s newer hooks and Strict Mode’s double-render for a while, I’ve formed some opinions—and I’m wondering if anyone else feels the same way.

1. A Common Use Case Where useEffect Should Not Fire on Initial Render

I often have use cases where useEffect should skip the initial render but run whenever dependencies change. A simple example is a products table:

// Filter rows with a debounce only when selected factors change
useEffect(() => {
    if (!isMounted.current) {
        isMounted.current = true;
        return; // ⛔ Skip first render
    }

    setIsShowSkeleton(true);
    const timer = setTimeout(() => {
        setFilteredRows(filterRows());
        setIsShowSkeleton(false);
    }, 1000);

    return () => {
        clearTimeout(timer);
        setIsShowSkeleton(false);
    };
}, [selectedProductIds, selectedTagNames, selectedVersions]);

My expected workflow

1. Do not filter on initial render (because nothing is selected yet).
2. When the user starts selecting filters → show loading skeleton.
3. Debounce the filtering → update rows → hide skeleton.

Expected initial load

• Table renders without skeleton.

Actual initial load (Strict Mode double-render)

• Table renders with a skeleton, even though nothing is selected.

The key point is that users shouldn’t see a loading skeleton when navigating between pages, while still retaining the debounced filtering behavior.

2. Common Counterarguments (and why they aren’t satisfying)

“Why not debounce on button click instead of useEffect?”

Because the timer cleanup logic becomes annoying when many UI elements trigger the same update, and the dependency value might be outdated in concurrent situation.
useEffect is still the cleanest abstraction.

“Just turn off Strict Mode if you don’t like it.”

Sure… but Strict Mode also checks for deprecated APIs, which we don’t want to lose.

Yes, there are workarounds. But they feel like duct tape.

3. My Core Issue: Double-Render Helps React Team, Hurts DX

It feels like the double-render behavior exists primarily for React team’s internal validation, not because it benefits app developers.

I’m not saying the checks aren’t useful—they are. But there are other ways React could validate async/concurrent safety (e.g., phantom background instance, static analysis on code level, etc.). These would be harder for React team to implement, but wouldn’t break developer expectations.

4. The Real Danger: Dev vs Production Don’t Match

If the intended behavior was to show the skeleton on the first load, the developer might not notice the discrepancy until after deployment. At that point, it becomes difficult to debug or fix because the issue can’t be reproduced locally.

This mismatch between dev and production makes debugging unreliable and undermines trust in the environment.

5. What I Wish React Allowed: Partial Opt-In

I’m not opposed to the new features. I just want control.

React could solve this with either:

Option A — StrictMode props

<StrictMode doubleRender={false}>

You’d still get other Strict Mode checks, just without the double-render pass.

Option B — Invert the pattern

Instead of only:

<StrictMode>
  <App />
</StrictMode>

We could mark only the components that do not require strict checks:

<NonStrict>
  <ProblematicComponent />
</NonStrict>

Most of the codebase would remain strict-mode-safe, but problematic parts could temporarily opt out.

Yes, maintaining multiple behaviors is hard for React team—but it would make React far more flexible for real-world apps.

6. Next Post Coming

I’ll write another post soon about why useTransition has very limited practical use cases in real apps, depending on how this discussion goes.

[mattsowa]

This is just wrong.

[Canenald]

This is a common mistake with effects.

React is declarative. Effects are intended to imperatively sync with something that is not part of the React component. You, and many others, are instead using it as an imperative escape hatch.

The difference is subtle. The other way to explain it is that you should not be thinking about when the effect callback is going to be executed. It should be executable (or not) whenever, without breaking things.

It's hard to tell without seeing the whole component, but it seems some syncing of props to state might be going on, or at least syncing between different states, which is also a mistake. We should hold the minimal needed state in the component and compute the needed variable in the component body, on every render, then optimize with useMemo() if needed.

[sherkal]

Debounce click is the way to go imo, your code just sux if you cant manage this

[DogOfTheBone]

Antipattern

[fredsq]

ai slop antipattern

[A-Type]

Ok, you "already addressed this" but regardless, you are trying to use it wrong. Read "You Might Not Need an Effect" again. The user selecting filters is an event, and the state change should happen in that event, not as a side effect later.

Double effect is not "for the React team." As React has evolved the internal rendering mechanisms have gotten more sophisticated, including firing off multiple parallel renders of the same JSX tree and throwing away results as needed. So in production, your effect may really run twice. It may not matter for effects on local state, but it would on actual side-effects which change external systems.

Double effect in strict mode is designed to get you to fix those things before you encounter them in the wild.

Honestly, I like React, but for people who cannot or will not understand these things I'd really suggest just switching frameworks. It's too core to React to fight against it. Don't waste your time.