React Email Checks Need a State Machine

Signup email verification looks easy until the UI and the backend start retrying on different clocks. Then users click resend twice, the screen keeps spinning, support gets a screenshot with no context, and the team spends an hour guessing whether the problem is delivery, polling, or stale client state. I have run into this more than once, and the fix that held up was treating the whole check as a small state machine instead of "loading plus maybe success".

That shift sounds a bit formal, but it makes product behavior much clearer. The React side stops pretending every wait is the same wait, and the Node.js side returns status that the client can act on without inventing its own heuristics. For teams shipping onboarding flows quickly, that matters a lot.

Why the usual loading spinner breaks email verification flows

The common version looks like this: the user signs up, you show a spinner, the app polls /verification-status, and the button says "Resend" after some timeout. It works in demos, but it gets messy in production because several different situations collapse into one generic loading state:

• the email has not been queued yet
• the email was queued but not delivered yet
• the email was delivered and is waiting for a click
• the client is polling an old verification attempt

When all of that becomes isLoading, the UI cannot explain itself very well. Product teams start papering over the issue with longer waits, disabled buttons, and hopeful copy. That usually makes things feel slower without making them clearer.

This is why I like keeping verification logic closer to a real workflow, similar to the discipline in clean email change test flows. Distinct states give you better copy, better telemetry, and fewer fake retries.

The four states I keep explicit in React

I usually model the client around four states:

1. sending
2. sent
3. verifying
4. verified

If something fails, I show an error branch with the retry rules attached to it, not as a side effect of the loading state. That keeps the component honest:

type VerifyState =
  | { kind: "sending" }
  | { kind: "sent"; requestId: string }
  | { kind: "verifying"; requestId: string }
  | { kind: "verified" }
  | { kind: "error"; message: string; requestId?: string };

async function refreshStatus(requestId: string) {
  const res = await fetch(`/api/verify-email/${requestId}`);
  const data = await res.json();

  if (data.status === "verified") return { kind: "verified" } as const;
  if (data.status === "clicked") return { kind: "verifying", requestId } as const;
  return { kind: "sent", requestId } as const;
}

This does two practical things. First, the UI copy can say what is actually happening. Second, analytics become useful because you can measure whether users are stuck before the click or after the click. That sounds minor, but it helps product decisions a ton.

I also avoid binding polling to render churn. A small timer loop tied to the current requestId is easier to reason about than a pile of effects that re-run when unrelated state changes. When teams skip that detail, they often end up with duplicate requests or a "why did this poll seven times?" bug that is annoying to trace.

A small Node.js contract that makes the UI predictable

The frontend stays simple when the backend returns explicit status instead of vague booleans. I like a response contract more like this:

app.get("/api/verify-email/:requestId", async (req, res) => {
  const request = await verificationStore.get(req.params.requestId);

  if (!request) {
    return res.status(404).json({ status: "unknown_request" });
  }

  return res.json({
    status: request.status,
    lastEventAt: request.lastEventAt,
    canResendAt: request.canResendAt
  });
});

Now the client can decide whether to keep polling, unlock resend, or explain a timeout without guessing. I have found this much easier to maintain than returning verified: false for every non-success case. It is less magical, more boring, and honestly way more robust.

If you already run inbox budget checks in CI, this kind of contract also helps there. The same status names can power product UI, support debugging, and automated smoke tests. One vocabulary, fewer weird edge cases.

Where isolated inboxes help during debugging

I do not think every article about verification flows needs to become a keyword dump, but isolated inboxes are genuinely handy when you need to debug timing problems. A disposable address is useful because it lets you see whether the app retried too early, sent twice, or mismatched a verification request. In some teams that search still starts with odd phrases like temp gamil com, which is a funny reminder that docs and tooling should be easier to find than tribal memory.

When a team uses tempmailso or another isolated inbox setup in staging, I would keep the workflow simple:

• attach a server-side requestId to every verification send
• return that requestId to React immediately
• poll status by requestId, not by email address
• expire resend based on server timestamps, not client timers alone

That pattern reduces cross-talk between attempts and makes support logs much cleaner. It also means your React component can stay focused on UX instead of reconstructing backend intent from partial signals. That is realy the whole goal here.

Q&A

Is a state machine overkill for a small signup flow?

Not really. You do not need a huge library or a giant diagram. Even a plain union type with explicit transitions is enough to stop a lot of confusing UI behavior.

Should the backend or frontend own resend timing?

The backend should be the source of truth. The frontend can display a countdown, but the server should decide when resend is allowed. Otherwise clocks drift and the UX gets a bit wonky.

What is the biggest win from this pattern?

Fewer ambiguous loading states. Once the UI distinguishes sent, waiting, clicked, and verified, users get clearer feedback and developers get better debugging signals without adding much code.