[Feature Request]: zod2 access to refinementData

in zod2 there’s no way anymore to access the refinementData.

This can be very convenient when we want to reuse the info to display hints in the GUI (e.g. The password must have between 5 and 10 characters, …)

We could simply add the refinement data as a property to the check function: e.g. in base.ts:

refinement = (
    check: (arg: Output) => any,
    refinementData: MakeErrorData | ((arg: Output) => MakeErrorData),
  ) => {
    const augmentedCheck = (val, ctx) => {
      if (!check(val)) {
        ctx.addError(
          typeof refinementData === 'function'
            ? refinementData(val)
            : refinementData,
        );
      }
    };
    augmentedCheck.refinementData = refinementData;
    return this._refinement(augmentedCheck);
  };

Then we can simply loop over all ZodTypeDef.checks and check the refinementData property is set

[tmtron]

As pointed out here in https://github.com/vriad/zod/issues/138#issuecomment-685433879 this approach causes a lot of code-duplication and a maintenance nightmare.

Code-duplication

Even in a mid-sized business app, that has only 20 entities with 10 properties each, that would mean to have 20 redundant meta-objects with, a total of 200 redundant meta-fields plus 200 input definitions in HTML and many more constants.
There is no need for this redundant code. It does not add any additional value. All the information is already defined on the zod object, so we can simply loop over the zod-fields and generate the meta-data and HTML form.
Even a default helpText can easily be generated and tweaked per use case: e.g. different messages when the field has min/max or both.

Maintenance

In many apps you will have a frontend (e.g. react or angular), some shared typescript code and a node-backend. The zod definition will be in shared code and can be used by the frontend and the backend.
Now if someone of the backend development team adds a new validation (e.g. the field just had min and now they add max), it is possible (even likely) that they forget to update the metadata or form.

[tmtron]

I don’t think custom error maps are useful in this case. I am happy with the individual error-messages. What I want is to get a meaningful description of what the user should input, This should be displayed before they even enter a value.

Example:

• temp = z.number().int().min(-10).max(30)
• When the form is shown, I want to display: “Enter an integer between -10 and 20”

So you suggest that I first check which type it is (string, number, etc.) and per type pass all possibly invalid values to safeParse() before I show the form?

e.g. when a field is an integer, execute ALL of these:

• temp.safeParse(Number.MIN_VALUE) to check for a minimum
• temp.safeParse(Number.MAX_VALUE) to check for a the maximum
• temp.safeParse(3.14) to check for integer

Then what should we pass for strings to check the max. length??

Sounds like a very bad idea to me - compared to just looping over the refinements directly…