About setLocale and addMethod

[aarisfauji]

I am experiencing an issue when using setLocale and addMethod in Yup. After creating a custom method phone and setting the locale, the error message returned is not what I expected.

Code Used

const yup = require("yup");

yup.setLocale({
  mixed: {
    default: () => ({ key: "mixed.default" }),
    required: () => ({ key: "mixed.required" }),
    notType: () => ({ key: "mixed.notType" }),
  },
  string: {
    default: () => ({ key: "string.default" }),
    phone: () => ({ key: "string.phone" }),
  },
});

yup.addMethod(yup.string, "phone", function () {
  return this.test(function (value) {
    // Todo: regex phone
    return this.createError();
  });
});

let schema = yup.object().shape({
  name: yup.string().required().phone(),
});

try {
  schema.validateSync({ name: "test only" });
} catch (err) {
  messages = err.errors.map((err) => {
    console.info(err);
  });
  // TODO: do something (messages)
}

Issue

When I run the code above, the error message I receive is:

{ key: 'mixed.default' }

I expected to get the message:

{ key: 'string.phone' }

Expectations

I would like to understand why the error message generated does not match my expectations and how to fix it so that the string.phone error message appears when validation fails on the phone method.

Versions

• Yup version: 1.4.0
• Node.js version: 20.13.1

Thank you for your help and clarification!

[thany]

The setLocale function only knows about the default keys, and ignores all others. If you use typescript, you can see this being enforced through typings as well.

This to me, is one of the great shortcomings of Yup. And you'll see that every example that shows how to fix this, is too simple: they assume you've already magiced up your translation from somewhere, to hardcode it into your schema. And I think we agree that translations, or translatable strings, do not belong in schemas.

So in short, good to report this. But I don't think this will realistically be fixed short term, if ever.

My workaround is to put these keys (e.g. 'string.phone') as the validation messages, and let your application pick them up as translation keys at the time of rendering the component that displays them. Downside is that it becomes quite annoying to have params together with your keys, and it requires a bit of extra pipework, but you might be able to make it work at least.

How exactly this workaround is piped together, completely depends on the framework (if any) of your choice.

[christoph-kluge]

I resolved this by adding a custom translation key property (e.g. i18nKey) within the addMethod’s params. This property is passed as an additional argument to the setLocale functions. As a result, when mixed.default is triggered and no message is provided, it attempts to use the i18nKey; otherwise, it falls back to the default message.

setLocale({
  mixed: {
    default: (props) => function(props) {
      const translationKey = props.i18nKey || 'mixed.default';

      return t(translationKey, {...props})
    }
  },
})

addMethod(string, 'startsWith', function(expected, message) {
  return this.test('startsWith', message, function(value) {
    const { createError } = this;
    return value?.toString().startsWith(expected) || createError({
      params: { 
        expected,                             // << additional key for interpolation
        i18nKey: "string.startsWith",         // << pass translation-key parameter
      },
    });
  });
});