A React component sends a welcome email from an effect and, after it went out twice, a teammate guarded it with a ref: `useEffect(() => { if (!sentRef.current) { sentRef.current = true; sendWelcomeEmail(userId); } }, [userId])`. Why is that guard the wrong fix, and what would you do instead?

## What the guard is really admitting A `useRef` guard around an effect body is a statement that the effect is firing more often than the author wants. That is worth taking literally: effects are designed to run whenever the component mounts and whenever a dependency changes, and React deliberately exercises that in development. If "run again" is unacceptable for this code, then "runs when the component is displayed" was the wrong trigger in the first place. Sending an email, charging a card, creating an order, incrementing a counter — these are consequences of an event, and they have a specific cause: the signup submitted, the button was pressed, the payment confirmed. That cause exists somewhere in the code, and it is where the call belongs. ## Why the guard does not even work **A ref is per component instance.** `useRef` gives a fresh object each time the component mounts. Unmount and remount — a route change and back, a parent re-keying the subtree, a tab that unmounts hidden content — and `sentRef.current` is `undefined` again. The second email arrives, just less often, which is worse than reliably arriving because it now looks like an intermittent bug. **A module-level flag has the opposite failure.** Hoisting the flag out of the component makes it survive remounts, but it is now global to the module for the lifetime of the page. Sign up a second account in the same session, or render two instances, and someone gets no email at all — a silent failure nobody reports. **The dependency array becomes a lie.** The array says `[userId]`, which reads as "re-run for each user". The guard means only the first user is ever handled. Anyone maintaining this later has to read the body to discover that the declared reactivity is fake. **It only covers this one call site.** Any other path that mounts the component with a new user, or any retry after a failure, is outside the guard's knowledge. ## The fix, in order of preference **Move it to the server, into the operation that caused it.** The account-creation endpoint knows exactly once that an account was created. Sending the welcome email there removes the client from the question entirely — no mount, no navigation, no double render can affect it. This is the answer an interviewer is usually listening for. **If it must be client-triggered, put it in the handler.** The submit handler that created the account calls it once, after the create succeeds, with `try`/`catch` around it. One cause, one call. **Make the operation idempotent.** Networks retry, users double-click, background jobs re-run. Give the request a stable idempotency key — the user id plus the email type is often enough — and let the server drop a repeat. This is what actually guarantees "exactly once", because no client-side flag can survive a reload, a second tab, or a lost response that the client retries. ## When the trigger genuinely is "this screen was reached" Sometimes the product requirement really is arrival-based: mark a notification read when its detail page is opened, record that an onboarding step was viewed. Here an effect is the correct trigger, because the cause is being displayed. The way to make it safe is not a ref, it is idempotency: a write that sets a flag to the same value twice costs nothing, and `PUT`-shaped semantics or an idempotency key makes the duplicate harmless. Say that explicitly — the distinction is between operations where repetition is free and operations where it is money or a message to a human. ## StrictMode is the messenger Development `<StrictMode>` mounts, unmounts and remounts each component so effects run twice. It did not create this bug; it revealed that the effect is not safe to run twice, which is exactly the property React requires of effects, since a real remount can happen at any time in production. Any answer that ends with "we turned off StrictMode" or "we added a ref so the double-invoke stops" has missed the diagnosis: the correct response is either to make the operation safe to repeat or to move it out of the effect. ```js // Caused by an event: it belongs with the event. async function handleSignup(form) { const user = await createAccount(form); // server sends the welcome email navigate(`/welcome/${user.id}`); } ```