Here is my proposal to support asynchronous schema parsing.

⚠️ This proposal introduces breaking changes, i.e. all zx.parseXXX methods are now asynchronous.

@rileytomasek Let me know if you're okay with this change or if you'd rather add asynchronous methods to zodix.

Fixes #19

Was using the package along with another that needed access to the request form data and was getting an error that the request was being locked, and wouldn't be able to complete the request because of this.

Made changes where it will now clone the request and do the parsing on that request instead of the actual request to then forward it onto other packages.

Here is a solution to support object entries in FormData which enables <input type="file" /> parsing.

FormData object entries are stringified before FormData is parsed using the URLSearchParams trick.

FormData object entries are not parsed by the default parser, making it rather versatile as it enables users to parse object entries of any type using a custom parser.

I had to make some typings generic in order to support custom parsed search params types.

Fixes #14.

using separate zod schema doen't work

🚀 ~ action ~ error TypeError: keyValidator._parse is not a function
    at ZodObject._parse (types.js:1188:37)
    at ZodObject._parseSync (types.js:109:29)
    at ZodObject.safeParse (types.js:139:29)
    at ZodObject.parse (types.js:120:29)
    at Object.parseForm (index.js:50:22)
    at async action (main.tsx:25:20)
    at async callLoaderOrAction (router.ts:2530:14)
    at async handleAction (router.ts:981:16)
    at async startNavigation (router.ts:904:26)
    at async Object.navigate (router.ts:784:12)

here the repo for reproduce: zodix-rr-reproduce

The docs include an example on how to parse multiple SearchParams with the same name, but there doesn't appear to be support for parsing an array from formData entries with the same name.

I'm trying to make file uploads type safe using zx.parseFormSafe but I'm not able to parse the NodeOnDiskFile class.

import type { ActionArgs } from "@remix-run/node";
import {
  json,
  NodeOnDiskFile,
  unstable_composeUploadHandlers,
  unstable_createFileUploadHandler,
  unstable_createMemoryUploadHandler,
  unstable_parseMultipartFormData,
} from "@remix-run/node";
import type { ZodError } from "zod";
import { z } from "zod";
import { zx } from "zodix";

function errorAtPath(error: ZodError, path: string) {
  return error.issues.find((issue) => issue.path[0] === path)?.message;
}

export async function action({ request }: ActionArgs) {
  const uploadHandler = unstable_composeUploadHandlers(
    unstable_createFileUploadHandler({
      maxPartSize: 5_000_000,
      file: ({ filename }) => filename,
    }),
    // parse everything else into memory
    unstable_createMemoryUploadHandler()
  );
  const formData = await unstable_parseMultipartFormData(
    request,
    uploadHandler
  );

  const results = await zx.parseFormSafe(formData, {
    file: z.instanceof(NodeOnDiskFile),
    // And some more fields that work just fine 👌
  });

  if (results.success) {
    return await doSomethingWithImage(results.data);
  } else {
    return json({
      success: results.success,
      error: errorAtPath(results.error, "image"),
    });
  }
}

formData.get("image") instanceof NodeOnDiskFile actually evaluates to true.

I found a rather similar issue on the zod repo where running z.instanceof(File) on the server resulted in a Reference Error because the File class is not defined in Node, which is not the case of NodeOnDiskFile.

I tried another method to parse the data which would result in an any type inference but would at least throw for missing data :

const results = await zx.parseFormSafe(formData, {
    image: z.any().refine((file: unknown) => {
      console.log({ file }); 
      return Boolean(file);
    }, "Image is required."),
  });

Which logged { file: '[object File]' } suggesting the file is casted to a string before it reaches the refinement function.

I don't know if this issue comes from zod or from zodix but maybe someone encountered the issue before and found a workaround.

Thanks!

These could combine the parsing of loaders/actions that use both params and query. Could look something like:

export async function loader(args: LoaderArgs) {
  const { id, count } = zx.parseLoader(args, {
    params: { id: z.string() },
    query: { count: zx.NumAsString },
  });
};

zod exports the parseAsync and safeParseAsync methods to handle asynchronous refinements and transforms.

If you use asynchronous refinements or transforms (more on those later), you'll need to use .parseAsync

It'd be great it zodix could support those to improve the overall compatibility with zod.

zx.parseFormSafe is able to parse ZodEffects schemas but it fails to infer the types. I added a failing test to reproduce issue #17 but I wasn't able to fix it instantly so I will leave it there for now. I will look into it next week probably.

@rileytomasek I did not dig into zod typings so far, do you have any idea how to handle this?

EDIT: I found a way to fix the type inference of result.error when user is parsing a ZodEffects schema with zx.parsFormSafe.

Fixes #17

I noticed the zx.parseFormSafe type inference does not handle well ZodEffects schemas resulting from the use of refine, superRefine or transform. I will create a PR with a failing test and go from there. Do you have any idea how to fix this?

Right now, the package uses @remix-run/node to get the LoaderArgs type (and if you accept #1 to get the FormData class).

This creates a hard requirement on Node as the runtime, but a Remix app could use Cloudflare or Deno as runtimes.

You can solve this by importing from @remix-run/server-runtime. The LoaderArgs type is exported from there and re-exported from the runtime packages, and this way you avoid the dependency on a runtime.