fix: input and output types

[sachinraja]

zfd.formData({
  name: zfd.text()
})._input

is now of type FormData instead of { name: string }.

const formDataSchema = zfd.formData({
  name: zfd.text()
})

const form = formDataSchema.parse(formData)

form is still typed as { name: string } here.

I need this type to be correct so input types are inferred accurately for a form data integration I'm working on for tRPC.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
remix-validated-form	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 22, 2023 at 3:06PM (UTC)

[airjp73]

This seems like a reasonable change, but I'll admit I don't fully understand the use-cases behind tracking the input type.

We might want to broaden the type though. This can be used when URLSearchParams, too, and I don't want to accidently forbid that usage. Technically we can use any Iterable that returns entries.

[sachinraja]

I broadened the type to this:

{
  [Symbol.iterator](): IterableIterator<[string, FormDataEntryValue]>;
  entries(): IterableIterator<[string, FormDataEntryValue]>;
}

URLSearchParams actually still works with the FormData type though.

The use case is that in tRPC we infer the type that users need to pass to their API using Zod's z.input<typeof schema>:

t.procedure
  .input(
    zfd.formData({
      name: zfd.text(),
    })
  )
  .mutation(({ input }) => {
    console.log(input);
  });

so on the client users can know exactly what they need to pass to this API function:

const formMutation = trpc.form.useMutation()

// type here must be FormData, automatically inferred from the server using `z.input`
formMutation.mutate(new FormData(e.currentTarget))
formData.mutate('hello') // this gives a TS type error

[airjp73]

Fantastic. Thanks for the detailed response. 😊

This looks good -- I'll publish as a major version bump.

[airjp73]

Published in v2.0.0