RHF + yup + i18next: anyone?

[nareshbhatia]

Has anyone tried internationalization of validation messages using yup + i18next?

Yup provides a way to do this using setLocale(), however it doesn't seem to work with RHF. For example, I have used setLocale like this:

yup.setLocale({
    mixed: {
        default: 'fieldInvalid',
        required: 'fieldRequired',
    },
    string: {
        required: 'fieldRequired',
    },
});

However, RHF seems to ignore it completely and I still get validation messages like "Email is a required field" instead of "fieldRequired" which I can send to i18next for translation.

[bluebill1049]

Don't think that works out the box right now, you may need to use custom resolver.

@jorisre I think this is something we can improve on the next major version to consider i18.

[nareshbhatia]

Any example of writing a custom resolver?

[jorisre]

Sure I'll think about :)

@nareshbhatia When I was using Yup, I encounter a similar issue: jquense/yup#293

[nareshbhatia]

@jorisre, I think yup has been fixed since then. yup.setLocal() is working just fine for me - outside of RHF. Please see https://codesandbox.io/s/practical-tdd-3zjv1?file=/src/index.test.js

[jorisre]

Thank for the csb, I think it's an issue with the yup resolver but we have to investigate to confirm it

[bluebill1049]

import * as React from "react";
import { useForm } from "react-hook-form";
import * as Joi from "joi";

const validationSchema = Joi.object({
  username: Joi.string()
    .alphanum()
    .min(3)
    .max(30)
    .required()
});

const App = () => {
  const { register, handleSubmit, errors } = useForm({
    resolver: async data => {
      const { error, value: values } = validationSchema.validate(data, {
        abortEarly: false
      });

      return {
        values: error ? {} : values,
        errors: error
          ? error.details.reduce((previous, currentError) => {
              return {
                ...previous,
                [currentError.path[0]]: currentError
              };
            }, {})
          : {}
      };
    }
  });

  const onSubmit = data => {
    console.log(data)
  };

  return (
    <div className="App">
      <h1>resolver</h1>
      
      <form onSubmit={handleSubmit(onSubmit)}>
        <label>Username</label>
        <input type="text" name="username" ref={register} />
        {errors.username && <p>errors.username.message</p>}
        <input type="submit" />
      </form>
    </div>
  );
};

[nareshbhatia]

Thanks, I will give it a try.

[nareshbhatia]

I finally got this working! You can try a live demo here. The source repo is here.

Interestingly enough, I didn't have to write a custom resolver. The big breakthrough came from my colleague @jamesxliu, who realized that we shouldn't be creating yup schemas statically. So instead of const addressSchema = yup.object().shape(...) we started creating it using a function const getAddressSchema = () => (yup.object().shape(...)). This allowed yup to create the schema based on the locale that was set using yup.setLocale().

Once this started working, we made bunch of other tweaks to make parameterized validations work e.g. min/max/invalid type etc. Here are some of the interesting files to look at:

1. ValidationError.ts: This is a data structure representing a validation error that can be translated using a translation file.
2. ErrorMessage.tsx: This component shows a ValidationError.
3. All form components now use the ErrorMessage component to show validation errors. For example, see TextField component.
4. Translation file now contains validation errors as tokenized strings. Tokens are enclosed in double curly-brackets, e.g. {{min}}. This is the format that i18next understands. See example here.

@bluebill1049, @jorisre, thank you for getting me started on this journey. If you have any suggestions for improvements, please let me know. Other than that, hope this example helps others who need to address i18n.

[bluebill1049]

This is awesome, let us know how we can make this easier as well. we are planning for the next major update, it's a good opportunity to improve on the developer experience here.

[balzdur]

I'm also facing the same issue in my company, for now, the solution we use is to translate error messages at validation time. This create multiple 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)

In order to raise those issues, the ideal solution would be to pass structured data as error messages (this is actually the solution used inside the provided repository). In short, using the types from RHF, something like this would do the job :

export declare type FieldError = {
    type: LiteralUnion<keyof RegisterOptions, string>;
    ref?: Ref;
    types?: MultipleFieldErrors;
    message?: Message;
};

// Extending the Message type so it's not only a string
export declare type Message = string | {key:string; values?: object};

With that, we could create error messages using parameters required by t function and thus, do the translation at the very last moment, when it comes to declare the JSX to render.

Anyway, RHF is not the only bloquer for such a solution. We are using zod to handle validation and the package also restrict error messages to be string.

[soullivaneuh]

@nareshbhatia Thanks for this complete sample, very useful! 👍

Looking at your sample on ErrorMessage, we can see you call t with a dynamic key variable.

I assume this is not working with a translation generation system like i18next-parser, am I right?

If not, do you have any suggestion about resolving that problematic? 🤔

[npearson72]

This is awesome, let us know how we can make this easier as well. we are planning for the next major update, it's a good opportunity to improve on the developer experience here.

@bluebill1049 was there any work since this discussion that could make using i18next react + yup + RHF easier?