useActionState retains state when using <Activity> — how to reset useActionState while preserving input value

[Mohamed-maher50]

Summary

I want to reset the formAction state on remount while preserving the input value, so that users don’t lose what they typed but the server action state starts fresh each time.

Additional information

Expected vs Actual Behavior:

Expected:

Input value persists when toggling visibility.

useActionState resets on remount so the formAction starts fresh.

Actual:

Input value persists ✅

useActionState retains success = true even after closing and reopening the form ❌
No response

Example

https://codesandbox.io/p/devbox/zrqrdd

[wesleysmyth]

The core issue is that <Activity> (the new name for <Offscreen>) preserves the entire subtree's state when mode="hidden" — including useActionState. This is by design: the whole point of <Activity> is to keep state alive so the UI can be instantly restored.

Solution 1: Key-based reset (simplest)

Force the form to remount when the Activity becomes visible by tying a key to a counter that increments each time:

const [resetKey, setResetKey] = useState(0);

// Call this when the Activity becomes visible again
const handleOpen = () => setResetKey(k => k + 1);

<Activity mode={isVisible ? "visible" : "hidden"}>
  <MyForm key={resetKey} />
</Activity>

Inside MyForm, useActionState starts fresh on every remount because the key change unmounts and remounts the component.

Solution 2: Hybrid — key the action, preserve the input

Separate the form into two components: one that owns the useActionState (keyed), and one that owns the input value (unkeyed):

function SearchPanel({ isVisible }: { isVisible: boolean }) {
  const [query, setQuery] = useState('');
  const [resetKey, setResetKey] = useState(0);

  useEffect(() => {
    if (isVisible) setResetKey(k => k + 1);
  }, [isVisible]);

  return (
    <Activity mode={isVisible ? "visible" : "hidden"}>
      {/* Input state survives because it's outside the keyed boundary */}
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {/* Action state resets because the key changes */}
      <ActionForm key={resetKey} query={query} />
    </Activity>
  );
}

function ActionForm({ query }: { query: string }) {
  const [state, formAction] = useActionState(submitAction, { error: null });
  return (
    <form action={formAction}>
      <input type="hidden" name="query" value={query} />
      <button type="submit">Search</button>
      {state.error && <p>{state.error}</p>}
    </form>
  );
}

The key approach is the idiomatic React solution — useActionState intentionally does not expose a .reset() method because React's model is that a new key means a new instance.

[Mohamed-maher50]

Hi wesleysmyth, thanks for your suggestion!

I understand the approach, but in my case I want to avoid putting form logic in the parent component. Keeping the submission and reset handling inside the form component itself keeps the logic self-contained, easier to reason about, and avoids coupling the parent to the child’s internal state.

[icyJoseph]

This kind of AntiActivty pattern, where you rotate a key to reset instance, as per, https://react.dev/learn/preserving-and-resetting-state#resetting-a-form-with-a-key, should not necessarily be the first way out of Activity. It may be valid if you model certain parts of the UI as being associated with a transaction id. Dropping in the key rotation should be the last escape hatch for UI under Activity.

Instance reset via key is a powerful, and not as widely used React technique! Useful for animation resets for example

In the other comment, for example, it looks ok-ish, but it sets state within a useEffect, which is not-recommended, this leads to double rendering by default. In the snippet it looks ok, in a larger component, it might not be so.

Also, as it is, you'll see a flash of the success state, because useEffect lets the browser paint. Switching to useLayoutEffect sounds like a way out of that, but again, in an expensive subtree, double rendering and not painting anything at all, will feel slow.

And unless, you go down that path of placing AntiActivity everywhere via a custom component, you'd be leaking logic to the parent of your component, to make them aware that they ought to reset one of their children state.

useActionState is an async reducer, where actions are dispatched to a queue, that updates state, one action at a time. So you can model it like this:

const [state, action, isPending] = useActionState(asyncReducer, initialState)

And the asyncReducer itself:

async function asyncReducer(prevState, next) {
    // Here you can fork into various paths
    // for example
   if (next.type === 'RESET') {
       return {/* some initial state */}
   }
   // otherwise trigger a server function, 
   // or any other sort of work, even router methods if you define
   // the reducer in closure 
   }

With that we can sketch a solution (I kept the types high level):

async function fakeAction(_prev: State, type?: unknown) {
  if (type === "RESET") return { success: false };
  await new Promise((r) => setTimeout(r, 500)); // server stuff or w.e.
  return { success: true };
}

And then via useLayoutEffect, dispatch a transition-action when the component is Activity-hidden:

const resetRef = useRef(false)

useLayoutEffect(() => {
    return () => {
      // When the Activity hides...
      if (resetRef.current) {
        resetRef.current = false
        startTransition(() => {
          action("RESET");
        });
      }
    };
  }, []);

  useEffect(() => {
    if (state.success) {
      console.log("Effect fired because success = true");
      resetRef.current = true;
    }
  }, [state.success]);

Alternatively, and actually the happier path, is when you inline the reducer into useActionState, and then you can set the resetRef.current, in the SUBMIT branch.

const [state, dispatchAction, isPending] = useActionState(
    async (prev, payload) => {
        switch (payload.type) {
            case 'SUBMIT':
                await submitAction(payload.data)
                resetRef.current = true; // This part doesn't have to be in an effect
                return { success: true }

            case 'RESET':
                return { success: false }

            default:
                throw new Error('not implemented')
        }
    },
    { success: false }
)

Codesandbox

Edit: fixed the flashing bit, I rushed to answer and had made a mistake :)

[Mohamed-maher50]

I get the idea of modeling useActionState like an async reducer, but in this case the suggestion doesn’t really fit my scenario.

My action needs to accept a real payload (FormData from the form). If I also start dispatching custom control actions (like RESET), I’d have to add extra branching logic inside the reducer to distinguish between FormData and action objects (for example checking the payload type). That adds complexity and mixes UI control flow with the submission payload handling.

Because of that, using useActionState as a generic action queue here doesn’t simplify things — it actually makes the reducer more coupled and harder to reason about. In this case, keeping the form submission payload-only and handling reset/visibility at the component level feels clearer and more predictable.

[icyJoseph]

“coupling / clear / predictable”

• useActionState gives you one input channel (the “payload” you pass to action(payload)).
• If you want that channel to carry both FormData and commands (RESET), you need a way to discriminate (type check, tagged union, separate function, etc.).

I wouldn't say that's "coupling", it is just what reducers are made for, transforming data given a new action, and for that certain logic per action is necessary.

And if we are gonna bring in coupling here, I think we can agree that, a reducer that handles:

• SUBMIT with FormData
• RESET with no payload

is less coupled than pushing reset responsibility up into parents via key-rotation, because of the reasons given above. So this solution is indeed not as coupled as other solutions could be.

Of course, a reducer that grows out of control can be problematic, but a two member branch is not that.

I think there's a case for better ergonomics though... if your current call site is a form action={action} expecting FormData, then passing non-FormData to the same action is odd indeed...

But there's ways around that, for example:

type Message =
  | { type: "SUBMIT"; data: FormData }
  | { type: "RESET" };

async function reducer(prev: State, message: Message) {
  if (message.type === "RESET") return {/* w.e. you reset to */};
  // message.type === "SUBMIT"
  return await submit(prev, msg.data);
}

Then make two dispatchers:

const [state, dispatch] = useActionState(reducer, initialState);

const submitAction = (data: FormData) => dispatch({ type: "SUBMIT", data });
const reset = () => dispatch({ type: "RESET" });

And pass submitAction to your form, and the Activity hiding uses reset. This makes intent clear.

On the recommended reset signal approach: https://react.dev/reference/react/useActionState#reset-state, they also bring this up, actually the whole document makes heavy use of the asyncReducer concept. It also mentions using a key to reset the instance, but yeah, I'd keep that as last resort.

[wesleysmyth]

Good callout. You're right that key rotation should be a last resort with <Activity>, not the default pattern. The whole point of Activity is state preservation — routinely defeating it via key rotation means you're fighting the abstraction.

A better first approach: treat the stale useActionState as a feature, not a bug. If the form was submitted successfully before the Activity was hidden, showing that success state when it comes back is arguably correct UX — the user can see what happened.

If you genuinely need a fresh form (e.g., a "new transaction" flow), the cleanest way is to model it at the data level:

function TransactionForm({ transactionId }: { transactionId: string }) {
  const [state, action] = useActionState(submitTransaction, {
    transactionId,
    status: "idle",
  });
  // Form resets naturally when transactionId changes
  // because the initial state is different
}

The parent controls the transaction lifecycle — when a new transaction starts, pass a new transactionId. The form state resets because the business context changed, not because we forced a remount.

And agreed on the useEffect setState point — that pattern in the second snippet was showing a quick escape hatch, but in production you'd want to avoid the double render. useSyncExternalStore or lifting state up would be cleaner for non-trivial cases.