Is there an equivalent of Zod's inferFlattenedErrors for with-zod?

[zayenz]

Zod has a method inferFlattenedErrors that gives a fully specified type for the errors. Is it possible to get a similarly fully typed error for a validator built with with-zod?

Currently the type of errors for a withZod constructed validator is

export type ValidatorError = {
  subaction?: string;
  formId?: string;
  fieldErrors: FieldErrors;
};

where the FieldErrors is a Record from and to string.

Compare with the following Zod code

const SomeData = z.discriminatedUnion("kind", [
    z.object({
        kind: z.literal("with-number"),
        num: z.number(),
    }),
    z.object({
        kind: z.literal("with-string"),
        str: z.string(),
    }),
]);

type ErrorType = z.inferFlattenedErrors<typeof SomeData>;

Here, ErrorType has the inferred format

type ErrorType = {
    formErrors: [];
    fieldErrors: {
        kind?: string[] | undefined;
        num?: string | undefined;
        str?: string | undefined;
    }
}

which specifies all the fields explicitly. This is quite useful for getting typescript based completion for ActionData in Remix.

My current work-around to avoid specifying the ActionData type explicitly with all the fields is ot use

const FormDataSchema = z.discriminatedUnion("subaction", [
    // ... List of schemas for subactions
]);

export interface ActionData {
    subaction?: string;
    formId?: string;
    fieldErrors?: z.inferFlattenedErrors<typeof FormDataSchema>["fieldErrors"];
}

This works well enough, but I will need to keep it up to date when/if the error type in with-zod changes.

[airjp73]

We don't currently have a way to infer the type of the error result -- the best we have is ValidationErrorResponseData which uses Record<string, string> for the field errors. I'm also not totally sure if we can provide this inference. z.inferFlattenedErrors doesn't produce an accurate type for our uses so we'd potentially have to find some way to implement this type from scratch for both zod and yup.

Example of why z.inferFlattenedErrors isn't accurate. If you have this schema

const s = z.object({
  names: z.array(z.string())
});

Then you get this type using z.inferFlattenedErrors

type ErrorType = z.inferFlattenedErrors<typeof s>['fieldErrors'];
// { names?: string[] | undefined }

But the correct type for the errors returned by the validator are actually

type ActualErrorType = {
  names?: string | undefined;
  'names[0]'?: string | undefined;
  'names[1]'?: string | undefined;
  // ...etc
}

I will probably change the structure of the field errors at some point in the future to be more like the flattened errors zod returns, but this is the situation right now.

Also, I'm curious: What's your use-case for accessing the error response directly? For the most part your errors will be provided automatically by useField.

[zayenz]

I haven't really used arrays in the types yet, and I get the problem.

Perhaps I will not have to use the errors explicitly in the page code when I've migrated my forms to all be remix-validated-form.

I do have some cases where I create the errors explicitly in the action function though, and in those cases it is nice to have accurate typing. As an example, when creating an element and say a unique name constraint is violated in the database I create an error indicating that this is the case. While such a check could also be made with a refinement, it is

1. unnecessary to make two calls to the database as the creation will check this, and
2. not enough anyway since between the refinement check and the actual creation, another creation could have happened.

[airjp73]

As an example, when creating an element and say a unique name constraint is violated in the database I create an error indicating that this is the case.

I think I'd approach this in one of two ways:

If you want the error to show for a particular field, you could use validationError and specify a field-specific error (see "Additional Validations" section on this page). In this case, the error would be picked up by your useField automatically so you don't need to handle it manually.

If you want to display the error in an alert or something not attached to a specific field, you could return your own payload outside the context of remix-validated-form and that would be easily typed since it's fully yours.

[zayenz]

Thanks. I will probably go with using the code from validationError for those cases, will work well enough.