React Router v7

[redjohnsh]

Hi, I'm trying out conform for the first time with the newly released react router v7 and I'm having a typescript type problem within useForm - lastResult property, particularly when using redirect inside my action. If I comment return redirect('...;) out, the error goes away. I'm thinking it is a react-router thing since the example expects remix, but still. Any ideas?

[edmundhung]

I haven't had the chance to explore React Router v7 yet. Could you share the error message you're seeing when you hover over the issue? Additionally, providing a StackBlitz link that reproduces the problem would be very helpful.

[jurajkrivda]

Type 'SubmissionResult<string[]> | { readonly headers: { append: undefined; delete: undefined; get: undefined; getSetCookie: undefined; has: undefined; set: undefined; forEach: undefined; entries: undefined; keys: undefined; values: undefined; [Symbol.iterator]: undefined; }; ... 13 more ...; text: undefined; } | undefined' is not assignable to type 'SubmissionResult<string[]> | null | undefined'.
  Type '{ readonly headers: { append: undefined; delete: undefined; get: undefined; getSetCookie: undefined; has: undefined; set: undefined; forEach: undefined; entries: undefined; keys: undefined; values: undefined; [Symbol.iterator]: undefined; }; ... 13 more ...; text: undefined; }' is not assignable to type 'SubmissionResult<string[]>'.
    Types of property 'status' are incompatible.
      Type 'number' is not assignable to type '"error" | "success" | undefined'.

It is something wrong with redirect from react-router

export async function action(args: Route.ActionArgs) {
  const formData = await args.request.formData();
  const submission = parseWithZod(formData, {
    schema: DeleteAcademySchema,
  });

  if (submission.status !== "success") {
    return submission.reply();
  }

  const { academyId } = submission.value;

  const academy = await prisma.academy.findFirst({
    select: { id: true },
    where: { id: academyId },
  });

  invariantResponse(academy, "Not found", { status: 404 });

  await prisma.academy.delete({
    where: { id: academyId },
  });

  return redirect("/academies");
}

export const DeleteAcademySchema = z.object({
  intent: z.literal("delete-academy"),
  academyId: z.string().min(1, "ID is required"),
});

export function DeleteAcademy({ id }: { id: string }) {
  const lastResult = useActionData<typeof action>();
  const isPending = useIsPending();
  const [form] = useForm({
    id: "delete-academy",
    lastResult,
  });

  return (
    <Form method="POST" {...getFormProps(form)}>
      <input type="hidden" name="academyId" value={id} />
      <button
        type="submit"
        name="intent"
        value="delete-academy"
        disabled={isPending}
      >
        {isPending ? "Deleting..." : "Delete"}
      </button>
    </Form>
  );
}

When I return submission (just for testing) instead of redirect the error disappears.

[edmundhung]

Great to know, thanks! Looks like this could be resolved by throwing the redirect response as mentioned here.

[jurajkrivda]

Throwing the response in this case is not a good idea I think.

[octet-stream]

You can just throw the result of the redirect function call instead of returning it. That way the error should not occur.

The redirect function returns a Response and you can throw responses from your actions and loaders if needed. This way you'll have only SubmissionResult as the returning type of your action.

Also, do not use useLoaderData and useActionData hooks - they are deprecated since latest releases of Remix. Use Route.ComponentProps instead to type props of your page's component and grab the data you need from the props.loaderData or props.actionData instead. Actually, I can't find any evidence that they're going to deprecated these hooks, so this doesn't matter, I think. But this is how current documentation suggest you access your data: https://reactrouter.com/start/framework/data-loading.

This is how I do it:

[jurajkrivda]

I really don't think throwing redirect is the way to go. Without Conform context, show me the documentation (RR7) where it says that throwing the redirect is a good solution.

[octet-stream]

Here you go, straight from Remix documentation: https://remix.run/docs/en/main/route/loader#throwing-responses-in-loaders

Along with returning responses, you can also throw Response objects from your loaders. This allows you to break through the call stack and do one of two things:

• Redirect to another URL
• Show an alternate UI with contextual data through the ErrorBoundary

And I use both of these things. It's pretty useful.

[octet-stream]

The RR7 documentation I would say is less clear about what can or cannot be thrown from loaders/actions: https://reactrouter.com/how-to/error-boundary#1-add-a-root-error-boundary

It rather incomplete, comparing to one for Remix.

All applications should at a minimum export a root error boundary. This one handles the three main cases:

• Thrown data with a status code and text
• Instances of errors with a stack trace
• Randomly thrown values

And then it says: https://reactrouter.com/how-to/error-boundary#2-write-a-bug

It's not recommended to intentionally throw errors to force the error boundary to render as a means of control flow. Error Boundaries are primarily for catching unintentional errors in your code.

But then documentation makes and exception for the rule 2: https://reactrouter.com/how-to/error-boundary#3-throw-data-in-loadersactions

There are exceptions to the rule in #2, especially 404s. You can intentionally throw data() (with a proper status code) to the closest error boundary when your loader can't find what it needs to render the page. Throw a 404 and move on.

So, they say in the RR7 docs that throwing data is ok, in case if you want to report an error with different status code, like 404. Do they mean you can only throw the data? Because returning data is the same as if you just return a data from loader/action except that you can also set additional params. And throwing is almost the same, but serialization is handled differently according to the docs. This function is needed just for that - so you don't have to serialize your data into Response object. But you still can return and throw it if needed.