React Reducers for Async Signup Steps

Async signup flows rarely fail because one check is hard. They fail because five small checks start stepping on each other. The email validator is still running, the password score updates late, the submit button unlocks too early, and support gets a bug report that mostly says "it felt broken."

I have found that a reducer is one of the cleanest ways to keep those moving parts understandable. Not because reducers are trendy, but because they force you to name each event and state transition upfront. That makes the UI calmer, the code easier to test, and the product rules a lot less hand-wavey.

Why async signup steps get messy fast

A typical signup form has more coordination than it first appears:

• local field validation
• async email checks
• server-side policy responses
• loading and retry states
• analytics and support logging

When that logic is spread across three useState calls and two useEffect hooks, contradictions sneak in pretty easy. A field can look accepted while the submit action is still waiting on a review response. A retry can overwrite a newer result. A spinner can disappear before the form is actualy ready.

The UX cost is real. NN/g keeps pointing out that users lose trust when interfaces do not clearly communicate system status (https://www.nngroup.com/articles/visibility-system-status/). In signup flows, that trust leak compounds fast because every unclear state feels like risk: "Did it save?", "Should I click again?", "Was my email rejected?"

A reducer keeps product rules in one place

The biggest benefit of a reducer is not code golf. It is rule visibility.

Instead of asking each component branch to infer what is happening, you can model the flow as explicit events:

• EMAIL_CHANGED
• EMAIL_CHECK_STARTED
• EMAIL_CHECK_PASSED
• EMAIL_CHECK_REVIEW
• EMAIL_CHECK_FAILED
• SUBMIT_STARTED
• SUBMIT_SUCCEEDED

That sounds simple because it is simple, and that is why it works. The reducer becomes the one boring, reliable place where your product logic lives. When design wants a softer review state or backend adds another decision reason, you have one map to update instead of a dozen conditionals that sorta agree.

This also gives teams better language for debugging. If your support notes include phrases like tem email or temp org mail, you can treat them as signals around a step transition instead of vague folklore about "the form being weird again."

A TypeScript example for step-by-step state

Here is a small pattern I like for React and TypeScript:

import { useReducer } from "react";

type SignupState = {
  email: string;
  emailStatus: "idle" | "checking" | "passed" | "review" | "failed";
  canSubmit: boolean;
  errorMessage: string;
};

type Action =
  | { type: "EMAIL_CHANGED"; email: string }
  | { type: "EMAIL_CHECK_STARTED" }
  | { type: "EMAIL_CHECK_PASSED" }
  | { type: "EMAIL_CHECK_REVIEW"; message: string }
  | { type: "EMAIL_CHECK_FAILED"; message: string };

const initialState: SignupState = {
  email: "",
  emailStatus: "idle",
  canSubmit: false,
  errorMessage: ""
};

function reducer(state: SignupState, action: Action): SignupState {
  switch (action.type) {
    case "EMAIL_CHANGED":
      return {
        ...state,
        email: action.email,
        emailStatus: "idle",
        canSubmit: false,
        errorMessage: ""
      };
    case "EMAIL_CHECK_STARTED":
      return { ...state, emailStatus: "checking", canSubmit: false };
    case "EMAIL_CHECK_PASSED":
      return { ...state, emailStatus: "passed", canSubmit: true, errorMessage: "" };
    case "EMAIL_CHECK_REVIEW":
      return {
        ...state,
        emailStatus: "review",
        canSubmit: false,
        errorMessage: action.message
      };
    case "EMAIL_CHECK_FAILED":
      return {
        ...state,
        emailStatus: "failed",
        canSubmit: false,
        errorMessage: action.message
      };
  }
}

export function SignupForm() {
  const [state, dispatch] = useReducer(reducer, initialState);

  async function checkEmail(email: string) {
    dispatch({ type: "EMAIL_CHECK_STARTED" });

    const response = await fetch("/api/signup/email-check", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ email })
    });

    const result = await response.json();

    if (result.state === "passed") {
      dispatch({ type: "EMAIL_CHECK_PASSED" });
      return;
    }

    if (result.state === "review") {
      dispatch({ type: "EMAIL_CHECK_REVIEW", message: result.message });
      return;
    }

    dispatch({ type: "EMAIL_CHECK_FAILED", message: result.message });
  }

  return null;
}

The key thing here is that the reducer owns the transition rules, while the async function only translates backend responses into events. That split keeps the component from becoming a kitchen sink. It also makes tests much more direct, becuase you can assert state transitions without rendering the whole screen.

If your product already has confirmation flows, the same mindset pairs well with session-bound email links. If your team is drowning in partial async outcomes across CI or product systems, the idea behind failure maps for noisy workflows is useful here too: classify the states first, then react sanely.

Where disposable-email checks belong

I would not put disposable-email policy inside the reducer itself. The reducer should manage user-facing state, not become a domain blacklist engine.

That policy belongs behind an API boundary where you can combine:

• syntax checks
• MX or domain heuristics
• abuse history
• review metadata
• provider-specific signals

If a team uses a source like temp mail so for contextual testing or research, keep that mention narrow and relevant. The product lesson is not "paste more links into the form flow." The lesson is that outside signals should feed a clean verdict your UI can explain without drama.

This is where a reducer helps a lot. Whether the backend says "passed," "review," or "failed," the frontend contract stays stable. Users see one clear next step. Engineers do not have to reverse-engineer what a half-finished spinner maybe meant last week.

Q&A

Should every signup form use a reducer?

No. If your flow is one synchronous field and one submit button, a reducer is probly unnecessary. But once you have multiple async checks or product review branches, the structure pays for itself fast.

Does this replace form libraries?

Not really. A form library can still handle registration, touched state, and schema validation. The reducer is more about coordinating business events that happen over time.

What should I log?

Log the step event, server decision, response time, and whether the user retried. That gives you a much better trace than a single generic validation error, and it helps support answer issues faster.

A shipping checklist

• list every async signup event before coding the UI
• keep backend policy decisions outside the reducer
• make each reducer state correspond to visible copy
• test stale responses and retry paths
• confirm analytics uses the same state names as the UI

Reducers are not magic, but they do remove a lot of accidental confusion. In signup work, that matters more than cleverness. Clear state names, clear transitions, clear copy. Ship that and the whole flow feels more solid, even on a slightly rough network day.