Don't express "only once" with a state that can come back — gate first-time behavior on a flag that remembers it already happened

The login button sometimes ignores the first click — but only when the user comes back from another tab. Sometimes you can even see it flicker into a skeleton for a moment. Or a welcome intro animation that should play once on first load replays every time the user scrolls back to the top. No errors anywhere. Reading the code, you find an innocent line like if (isLoading) return <Skeleton /> or if (scrollY < 100) playIntro().

State values do not say "first time"

State values such as isLoading, status === "loading" or distance <= X describe now; they do not say whether this is the first time. If something must happen only once — the first-load placeholder, an entry animation, a first-visit hint — and you tie it to such a state, it happens again every time that state comes back. Decide "first time" with a separate value that remembers it has already passed.

A state comes back in more ways than you expect:

• Revalidation: many hooks re-check the session or data when the window regains focus (useSession, refetchOnWindowFocus defaults). The loading flag flips on briefly
• User input: zoom, scroll and back navigation recreate the same distance or position
• Re-rendering: when a parent re-renders or a component remounts, the condition is evaluated from scratch

Why the first click disappears

Picture a header that swaps the login button for a skeleton while a loading flag is on. The user returns from another window and reaches for the button; at that exact moment, focus revalidation turns the flag on. The button leaves the DOM and a placeholder takes its spot. The click lands on the placeholder, and a few hundred milliseconds later the button is back. The user only experiences "I clicked and nothing happened". Nothing is logged.

Data-fetching libraries separate these two meanings on purpose. TanStack Query distinguishes "no data yet" (isPending) from "fetching right now" (isFetching) (TanStack Query docs). SWR separates the first load (isLoading) from background re-checks (isValidating). A placeholder belongs only on the first one.

How do you make "only once" actually happen once?

1. Name the one-time event. "First session check", "intro sequence", "first-visit hint". Do not leave it as one line hidden inside a state condition
2. Keep a value that remembers it has passed. hasResolvedOnce, introDone, a phase value. Once it turns on, it never turns off
3. Put the state condition behind that value. !introDone && distance <= X, !hasResolvedOnce && isLoading
4. Test the path back. Write tests that recreate the state: "after the intro, the effect strength is 0 at every distance", "after the first check, the button stays during revalidation"

// Before: the button vanishes on every revalidation
if (status === "loading") return <Skeleton />;

// After: placeholder only until the first check resolves
const [resolvedOnce, setResolvedOnce] = useState(false);
useEffect(() => {
  if (status !== "loading") setResolvedOnce(true); // never turns back off
}, [status]);
if (!resolvedOnce) return <Skeleton />;

A rule to paste into code review notes or agent instructions:

Do not tie one-time behavior (first-load placeholder, entry animation, first-visit hint)
directly to "current" state such as isLoading, status, distance or scroll position.
Gate it first with a value that remembers it already happened (a phase or flag),
and test that recreating the state (focus return, navigating back, remount) does not trigger it again.

What happened to us

• The lost first click on login — a web service header swapped its login button for a placeholder based on the session hook's loading flag. Only the first click after returning from another window sometimes failed: the focus-triggered session re-check flipped the flag on and the button had become a placeholder at that instant. We fixed it by showing the placeholder only until the first check
• A landing effect that replayed — in a 3D scene, a landing effect meant to run once during the intro was gated on "camera distance <= X". Whenever a user zoomed in to that distance with the mouse wheel, the camera seemed to lift and settle again. An earlier fix to the camera pitch did not remove the symptom, which is how we found a second effect stacked at the same spot. We gated it on an intro-phase flag and locked "zero at every distance outside the intro" into a test

In both cases the condition itself was correct. What was wrong was believing the condition meant "first time".