DEV Community

ryanlee
ryanlee

Posted on

Share Signup Email Rules Across React and Node

#javascript #webdev #react #node

Signup email rules tend to drift in a very boring way. The React form warns about one thing, the Node API rejects another, and support gets a screenshot that doesnt match the server log. It happens a lot when teams add temporary inbox checks late in the flow instead of treating email policy like a shared product rule from day one.

When the UI and API read from the same rule set, the feature gets calmer fast. Fewer false retries, fewer "works on my machine" moments, and a much clearer path for QA when somebody tests with a temp org mail or some random tem email they found in old notes.

Why signup email rules drift between React and Node

Most teams start with good intent:

  • React checks whether the email looks valid
  • Node checks whether the email can be accepted
  • the mail worker decides whether to send verification

That split sounds fine, but it creates drift. One layer blocks a domain, another only flags it, and a third silently queues the message anyway. By the time a user presses resend, nobody is totaly sure which rule fired first.

The fix is not another regex in the component. The fix is one policy object with a tiny surface area and predictable outcomes.

Store one policy object and share its decisions

I like to define email policy in plain JavaScript or TypeScript with decisions that the frontend and backend can both understand.

export type EmailDecision =
  | { kind: "allow" }
  | { kind: "review"; reason: "temporary-domain" | "role-address" }
  | { kind: "block"; reason: "invalid-format" | "banned-domain" };

export function evaluateEmail(email: string): EmailDecision {
  const normalized = email.trim().toLowerCase();

  if (!normalized.includes("@")) {
    return { kind: "block", reason: "invalid-format" };
  }

  if (normalized.endsWith("@example-bad.com")) {
    return { kind: "block", reason: "banned-domain" };
  }

  if (normalized.startsWith("admin@")) {
    return { kind: "review", reason: "role-address" };
  }

  return { kind: "allow" };
}
Enter fullscreen mode Exit fullscreen mode

React can call this before submit to show useful copy. Node can call the same function before creating the signup request. The important bit is that both layers return the same decision names, not thier own homemade interpretations.

In the UI, that means less vague messaging:

  • allow: continue normally
  • review: continue, but explain what happens next
  • block: stop early and tell the user what to fix

If you keep those outcomes stable, analytics and logs become much easier to read. That is the same reason I like replayable debugging for one run: one run should have one understandable story.

Return explicit API outcomes instead of vague failures

The backend should not just throw 400 Bad Request and call it a day. Return an outcome that the client can map directly.

app.post("/api/signup", async (req, res) => {
  const decision = evaluateEmail(req.body.email);

  if (decision.kind === "block") {
    return res.status(422).json(decision);
  }

  const signup = await createSignup(req.body.email, { decision });
  return res.status(202).json({
    status: "verification-pending",
    signupId: signup.id,
    decision,
  });
});
Enter fullscreen mode Exit fullscreen mode

This keeps the frontend honest. It also makes resend flows saner, because the client can store both the signupId and the original decision instead of guessing from a generic error toast. Small thing, big payoff.

One tradeoff: shared policy code can tempt teams to stuff everything into one package. Dont do that. Keep the policy narrow. Domain checks, basic classification, and human-readable reasons are enough for most web apps. Delivery retries, queue health, and anti-abuse heuristics still belong server-side.

Use temporary inboxes only as evidence, not policy

This is where teams get tangled. They start using a get temporary email workflow as if the inbox provider defines product policy. It should not. The inbox is evidence for a test or support check, not the source of truth.

For manual QA, I want three things:

  • the policy decision returned by the API
  • the signup or request id visible in logs
  • one isolated inbox for the current run

That approach lines up with clear inbox boundaries for auth flows. If your team uses a temp mail so link during smoke tests, tie it to the request id you already show in the app. If you need a quick disposable address for preview testing, treat it as run evidence only, never as the logic that decides whether signup is allowed.

That distinction matters more than people expect. Once inbox tooling starts driving policy, the system gets weird realy fast and no one can explain why one environment passed while another failed.

Quick Q&A

Should React import backend code directly?

Sometimes yes, often no. Share the tiny evaluation module, not the whole API layer. Keep it boring and dependency-light so bundling does not turn into its own problem.

What about feature flags?

Great fit. Flags let you switch a rule from review to block without rewriting the UI contract. Just make sure the returned decision names stay stable, or the client logic gets messy again.

Do I still need server-side validation?

Absolutely. The shared policy improves consistency, but Node remains the final authority. React is there to guide the user, not to enforce trust by itself.

When signup email rules are shared, your product stops arguing with itself. The code is simpler, QA gets cleaner evidence, and users get fewer confusing loops. For a feature that seems small on paper, thats a pretty solid return.

Top comments (0)