Extend Error message type for better support of i18next

[romankoho]

The error message type is limited to being a string.
This makes things complicated when it comes to localization of error messages in combination with resolvers and form libraries like react-hook-form.

There was basically the same discussion in the yup repository:
https://github.com/orgs/react-hook-form/discussions/3808#discussioncomment-2150621

@balzdur summarized it pretty well.

there are these two issues:

• since RHF use some memoization on error messages, translation isn't recomputed after a "change locale event"

• every schema is computed from a hook that use the useTranslate hook under the hood (not very suitable since the ideal solution would be to declare schema outside the React lifecycle)

The goal would be to do the translation at the very last moment when it comes to rendering / declaring the JSX

export interface $ZodErrorMap<T extends $ZodIssueBase = $ZodIssue> {
    (issue: $ZodRawIssue<T>): {
        message: string |  {key:string; values?: object};         // extend message type
    } | string | undefined | null;
}

[seedydocloop]

Hey @romankoho 👋

I'm facing a similar issue : I am using i18next with typescript (https://www.i18next.com/overview/typescript) to get intellisense for translations and rely on type safety.

Therefore, my translation keys are string literals instead of simple strings :

t($ => $['my.key'])

To keep static zod schema definitions, I am giving only the keys to my zod errors, for instance :

// schema.ts
export const SOME_SCHEMA = z.object({
  description: z.string("field.invalid").min(1, "field.required"),
});

I then rely on rendering inside components to make sure my translations are recomputed whenever language changes :

// component.tsx
return (
  {errors.description?.message && (
    {t($ => $[errors.description.message]}
  })
)

This is my best option so far, to keep schemas and i18n decorrelated.

I'd need a way to infer the possible types of an error message based on its schema definition :

t($ => $[errors.description.message] 
// ideal type for message : 'field.invalid' | 'field.required'

I expect this to be a bit expensive for ts and computations, but I'd need feedback from the community, or other ideas that also circumvent the issues @romankoho mentions :

since RHF use some memoization on error messages, translation isn't recomputed after a "change locale event"

every schema is computed from a hook that use the useTranslate hook under the hood (not very suitable since the ideal solution would be to declare schema outside the React lifecycle)

Thanks in advance, all 🙏

[romankoho]

would this also work with interpolation?

saying your i18next key is e.g. "Please enter at least {{minValue}} characters"

I assume this is not working? I also thought of just using translation keys in the schema definition but I hit this boundary.

[PunitSoniME]

@romankoho

Interpolation will work with the solution which I gave

[seedydocloop]

@romankoho you are right that my workaround does not work with interpolation.

There is no built-in mechanism in zod to make this interpolation job easy.

@PunitSoniME proposal allows you to write the code once and never think about it for a while, but brings strong requirements on your translation logic while maintaining code tightly coupled to zod that you'll have to update over time and releases.
I cannot go with it, while I respect the hard work you did !

To anwer your need following my implementation, I'd go with :

1. a shared constant holding minValue for both your schema and your translation

// schema.ts
export const SOMETHING_MIN_VALUE = 5;

export const SOME_SCHEMA = z.object({
  description: z.string("field.invalid").min(SOMETHING_MIN_VALUE, "field.required"),
});

2. reusing that variable whenever you hit the key

This avoids trying to build a specific workaround and coupling your translation logic with zod schemas.

The downside is that you are forced to tightly couple a translation key to its expected metadata, but in the end, that's what you want to do.
You couple the error key to the metadata you expect and share it between 2 systems that work independently.

// component.tsx
return (
  {errors.description?.message && (
    {t($ => $[errors.description.message], errors.description.message === "field.required" ? {
      minValue: SOMETHING_MIN_VALUE
    } : {}}
  })
)

This is a bit cumbersome to write, but easier to maintain. Anyone coming across this will find the SOMETHING_MIN_VALUE variable and see it used in both your translation and schema.

[PunitSoniME]

Hi

I was facing the similar kind of issue, and also wanted translations to be changed as soon as the language change

So here is the workaround and it is working perfect for me, however it needs some manual configuration to be done

export const USER_SCHEMA_VALIDATION = {
	username: z.string().trim().min(1, '_common::username').max(50, '_common::username'),
	password: z.string().trim().min(1, '_common::password')
}

/*
Here **_common** is a namespace and **username** is a key in my translation files

en-US > _common.json
{
    "username": "Username",
    "password": "Password",
    "validation_messages": {
		"enter_valid": "Enter valid {{text, lowercase}}",
		"fix_errors_to_proceed": "Fix errors to proceed",
		"is_required": "{{text}} is required",
		"max_length": "The maximum length for a {{text, lowercase}} is {{length}}",
		"min_length": "{{text}} is too short. Minimum {{length}} characters required",
		"must_be_less_than": "{{text}} must be less than {{limit}}",
		"must_be_more_than": "{{text}} must be more than {{limit}}",
		"must_be_number": "{{text}} must be number"
	},
}
*/

Below is my code to display error messages ( Can be different at your side, I am using shadcn FieldError component to display error and using Tanstack Form

const TranslatedErrors = ({ field }) => {
	const { t } = useTranslation(["en-US", "en-GB", "hi-IN"])

	const errors = field.state.meta.errors

	const modifiedErrors = useMemo(
		() =>
			errors?.map((issue) => {
				let message = issue.message
				//	If the error is not from translation, return as it is
				if (message.indexOf('::') === -1) return { message }

				//	[0] will be namespace, [1] will be the actual key
				const messageBlocks = message.split('::')
				const messageFromTranslation = t(($) => $[messageBlocks[1]], {
					ns: messageBlocks[0]
				})

				if (issue.origin === 'number') {
					if (issue.code === 'too_small') {
						message = t(($) => $.validation_messages.must_be_more_than, {
							text: messageFromTranslation,
							limit: issue.minimum
						})
					} else if (issue.code === 'too_big') {
						message = t(($) => $.validation_messages.must_be_less_than, {
							text: messageFromTranslation,
							limit: issue.maximum
						})
					}
				} else if (issue.origin === 'string') {
					if (issue.code === 'too_small') {
						message = t(($) => $.validation_messages.is_required, {
							text: messageFromTranslation
						})
					} else if (issue.code === 'too_big') {
						message = t(($) => $.validation_messages.max_length, {
							text: messageFromTranslation,
							length: issue.maximum
						})
					} else if (issue.code === 'invalid_format') {
						message = t(($) => $.validation_messages.enter_valid, {
							text: messageFromTranslation
						})
					}
				}

				return { message }
			}),
		[t]
	)

	return <FieldError errors={modifiedErrors} />
}

I hope this helps

If zod had meta key availability in errors object, that would be amazing, it will reduce passing the "namespace::key" in all validation types

Let's connect on
X ( Twitter ) - https://x.com/PunitSoniME
Linkedin - https://linkedin.com/in/punitsonime

[romankoho]

thanks for your solution. It surely is a workaround but in my eyes it makes things much more inconvenient (from a DX perspective) compared to accepting {key:string; values?: object}as error message as proposed by me.

[seedydocloop]

@romankoho your workaround seems too unreliable to me.

1. Your code breaks if the expected namespace is not loaded

const { t } = useTranslation(["en-US", "en-GB", "hi-IN"])

You could pass a different namespace in your schema, which would break translation in case your translations are lazy loaded.

2. You rely on types that you do not control

issue.origin and issue.code cannot be manually changed

3. You remap meta from zod into specific keys, which is not scalable

message = t(($) => $.validation_messages.must_be_less_than, {
							text: messageFromTranslation,
							limit: issue.maximum
						})

limit => issue.maximum

Having all zod's error metadata remapped would make more sense. I couldn't find a way to do it without coupling your code to zod, which means extra maintenance over time