Form actions и useActionState: мутации как первоклассный примитив React

Примитив: форма, чей action — функция

React 19 расширяет HTML-атрибут action: вместо URL можно передать функцию. На сабмите React отменяет дефолтную навигацию, собирает FormData из именованных полей формы и вызывает вашу функцию с ним внутри transition — UI остаётся отзывчивым, пока идёт асинхронная работа, а pending-состояние React отслеживает за вас. Когда action разрешился, React автоматически сбрасывает uncontrolled-поля (та пост-сабмитная очистка, которую раньше писали руками). Поля приезжают через атрибуты name, что тихо реабилитирует uncontrolled-стиль из первого урока: с actions большинству полей формы вообще не нужно посимвольное состояние.

useActionState — половина примитива, отвечающая за состояние. Вы отдаёте ему async-функцию редьюсерной формы — предыдущее состояние на входе, FormData на входе, новое состояние на выходе — плюс начальное состояние, и получаете три вещи: текущее состояние, обёрнутый action для формы и isPending.

async function subscribe(prevState, formData) {
  const email = formData.get("email");
  const parsed = emailSchema.safeParse(email);
  if (!parsed.success) {
    return { ok: false, error: "Enter a valid email", email };
  }
  const res = await api.subscribe(parsed.data);
  if (!res.ok) {
    return { ok: false, error: "Try again in a minute", email };
  }
  return { ok: true, error: null, email: "" };
}

function SignupForm() {
  const [state, formAction, isPending] = useActionState(subscribe, {
    ok: false,
    error: null,
    email: "",
  });

  return (
    <form action={formAction}>
      <input name="email" defaultValue={state.email} />
      <button disabled={isPending}>
        {isPending ? "Subscribing…" : "Subscribe"}
      </button>
      {state.error ? <p role="alert">{state.error}</p> : null}
    </form>
  );
}

Прочитайте форму внимательно: action — это редьюсер над сабмитами. Каждый сабмит берёт предыдущее состояние и производит следующее — поэтому важно возвращать отвергнутый email обратно в состояние: при провале, отрендеренном сервером, инпут можно засеять заново, а не стирать. Последовательные сабмиты выстраиваются в очередь: если пользователь отправил дважды, второй action ждёт первого, и каждый получает действительно последнее состояние — записи не перемешиваются.

isPending и useFormStatus: два масштаба pending

isPending из useActionState говорит, что этот action в полёте — используйте его там, где живёт владелец формы. useFormStatus отвечает на другой вопрос из другого места: вызванный в компоненте, отрендеренном под формой, он возвращает pending-состояние (плюс летящий FormData) ближайшей объемлющей формы — как контекст, предоставленный самим элементом формы. Это делает компонент SubmitButton переиспользуемым во всех формах кодовой базы без проброса pending-флагов:

function SubmitButton({ children }) {
  const { pending } = useFormStatus();
  return <button disabled={pending}>{pending ? "Working…" : children}</button>;
}

Классический провал: вызвать useFormStatus в том же компоненте, который рендерит <form>. Хук читает статус родительской формы, а её нет — pending навсегда false, кнопка не отключается, и ничего не падает. Хук обязан жить в потомке формы.

Progressive enhancement: форма, работающая раньше React

А вот часть, меняющая архитектуру. С серверными функциями фреймворка (функция с пометкой "use server", переданная в action) фреймворк сериализует ссылку на неё прямо в HTML. Если пользователь отправляет форму до гидрации — то самое черно-пятничное окно — браузер выполняет обычный нативный POST на сервер, фреймворк маршрутизирует его в ту же функцию, и страница перерендеривается с результатом. Ноль JavaScript на клиенте. После гидрации та же форма апгрейдится: сабмит становится transition на месте, с isPending, без навигации, с сохранёнными полями. useActionState тоже участвует — его необязательный третий аргумент permalink говорит no-JS-POST-у, на какой URL целиться, чтобы серверный круг приземлился на нужную страницу.

Это и есть унификация, к которой шёл весь юнит: клиентская и серверная мутации — одно объявление. Функция action — единственное место, где живёт мутация: валидация (общая zod-схема из прошлого урока встаёт дословно), запись и следующее состояние. Выполнится ли она локальным async-вызовом или сериализованным серверным кругом — деталь деплоя, а не архитектурная развилка. Дисциплина, которой это требует: моделируйте форму так, чтобы она могла работать без JS — именованные поля, исход, возвращаемый состоянием, а не императивным тостом, — и улучшенная версия наследует корректность от деградированной, а не наоборот.