Better type inference for formAction result

[atoi]

Currently formAction returns Promise<Response> which is usually okay, but makes my life complicated when I need to infer the shape of the result for useFetcher.

Yes, I know I can achieve what I want by using type utils from domain-functions, but how cool would it be if that happened automagically =)

Form action behavior:

export async function action({ request }: ActionArgs) {
  return formAction({
    request,
    schema: z.any(),
    mutation: makeDomainFunction(z.any())(async () => {
      return { ok: true };
    }),
  });
}

export default function FormRoute() {
  const fetcher = useFetcher<typeof action>(); // FetcherWithComponents<any>
}

Normal action behavior:

export async function action({ request }: ActionArgs) {
  return json({ ok: true });
}

export default function FormRoute() {
  const fetcher = useFetcher<typeof action>();
  // FetcherWithComponents<SerializeObject<UndefinedToOptional<{
  //  ok: boolean;
  // }>>>
}

[pkasarda]

What I have done is this

// fromAction returns
Promise<TypedResponse<FormActionFailure<Schema> | FormActionSuccess<D>>>

// and code
if (...) {
      return path ? redirect(path) : json({ errors: null, data: result.data });
    } else {
        return json({ errors: result.errors, values: result.values }, { status: 422 });
   }

then types are correct

    // this is when we have errors you have access to errors and values (internally used by HookForm)
    if (actionData?.errors) {
        actionData.errors;
        actionData.values;

        // if errors are null we have access to response from action
    } else if (actionData?.data) {
        actionData.data.abc;
        // @ts-expect-error this should trigger error
        actionData.data.nonExist;
    }

issue is here https://github.com/seasonedcc/remix-forms/blob/main/packages/remix-forms/src/mutations.ts#L108
it returns Promise<Response>

[atoi]

Yes, spend some time thinking on that piece already...
First I was considering changing the return type to be dependent on successPath value, but we also need to account for error case, so we'd need a type guard in the handler anyways...
As it seems there's must be some app code to properly type the result anyways -- no need to touch the library code then.