custom error messages

[jota]

Hey there,
great work with superstruct. I was especially happy to see that it does not bloat the browser bundle like other validation libs do.

One thing is holding me back to switch to superstruct though,

I could not find an easy way to provide a custom error message.

I was looking for something as easy as
pattern(string(), /^\d\d\d\d-\d\d-\d\d$/, 'custom error message, the string should be in date format YYYY-MM-DD')

or
message(pattern(...), 'custom error message, the string should be in date format YYYY-MM-DD')

The default error message provides the regex used which is not something I would like to bother a user with and there are some other use cases like localization.

Is there a way to do that already?

[ianstormtaylor]

Hey @jota can you explain your use case fully? Eg. what the specific struct is used to validate, where these error messages are going, etc. (with code samples)

[jota]

Hi Ian,

sure. Basically I would like to override the generated error message.

Let's say I have an object with a "date" field where I validate the format YYYY-MM-DD e.g. 2020-12-01.
Validation: date: pattern(string(), /^\d\d\d\d-\d\d-\d\d$/),
Input: 2020-12-XX
Error message: 'At path: date -- Expected a string matching /^\\d\\d\\d\\d-\\d\\d-\\d\\d$/ but received "2020-12-XX"'

I would like to change the error message to something else like "date should match format YYYY-MM-DD" because i would like to directly show those messages in a user interface.

I have created a jsfiddle here

I'm currently using yup, where I can use the following:
date: yup.string().required().matches(/^\d\d\d\d-\d\d-\d\d$/, 'date must have format YYYY-MM-DD'),

Does that make sense to you?

[ianstormtaylor]

My general recommendation is that I wouldn't necessarily show these error messages directly to a user, because Superstruct provides no guarantee that they are user-facing. Depending on the structure of your validation they could be very confusing.

I don't think I want to add a message argument to every struct because it gets tedious, but also because it makes it hard to compose them if the messages themselves assume things about where the structs are used.

That said, I'd be open to a message(..., string) utility function if you were down to pull request one.

The other solution for you is to define a custom type of your own, especially if you are planning to re-use those date strings in other places in your app, for example:

import { define } from 'superstruct'

const datestring = () => define('datestring', value => ... || 'My custom message.')

[jota]

Your second suggestion pointed me in the right direction.

Now i'm using:

const datestring = define('datestring', (value, context) => {
	if (/^\d\d\d\d-\d\d-\d\d$/.test(String(value))) {
		return [];
	} else {
		return {
                        path: [],
			message: `${context.path} must have format YYYY-MM-DD`,
		};
	}
});

and the error message is "date must have format YYYY-MM-DD".

That works for me, thank you for taking the time!

[richarddavenport]

My general recommendation is that I wouldn't necessarily show these error messages directly to a user, because Superstruct provides no guarantee that they are user-facing. Depending on the structure of your validation they could be very confusing.

I don't think I want to add a message argument to every struct because it gets tedious, but also because it makes it hard to compose them if the messages themselves assume things about where the structs are used.

That said, I'd be open to a message(..., string) utility function if you were down to pull request one.

The other solution for you is to define a custom type of your own, especially if you are planning to re-use those date strings in other places in your app, for example:

import { define } from 'superstruct'

const datestring = () => define('datestring', value => ... || 'My custom message.')

@ianstormtaylor Just curious... are you saying that we could create a utility function (message()) that would take in an error struct/something else(?) and it would spit out user facing error messages?

This library is by far the best, the only thing I'm needing is user facing error messages.

[EvgenBabenko]

@richarddavenport totally agree with u, we realy need this feature
with TS create custom structs looks like i just override all library with this tons of generics and types

[ianstormtaylor]

Hey @richarddavenport can you give me an idea for what your use case is for user-facing error messages? There are a few different ways I might recommend doing it.

[richarddavenport]

@ianstormtaylor thanks for being open. Let me through together some notes/code.

[EvgenBabenko]

@ianstormtaylor hi, i've created a new PR with custom errors and i think in this way all of us wanted see custom errors in others functions

[richarddavenport]

@EvgenBabenko I think the goal of this issue is to be able to see User facing error messages. For example if a form input is required (like name) then you would validate with superstruct and then if you need to show the user a message you could do it with a custom message.

Example:

const User = object({
  name: string(),
});
const data = {
  name: null,
};
assert(data, User);
// produces:
{
  "message": "At path: name -- Expected a string, but received: null",
  "value": null,
  "type": "string",
  "path": [
    "name"
  ],
  "branch": [
    {
      "name": null
    },
    null
  ]
}

Given the previous I would not show the user a toast notification displaying "At path: name -- Expected a string, but received: null". Superstruct is very useful for the developer but not the user... I would rather show the user "Name is required"

[EvgenBabenko]

@richarddavenport so, we have different approaches for show messages to users, cuz we're using react-hook-form and we're trying connect react-hook-form with superstruct instead Yup
I've prepared codesanbox example. I've created required struct, but it doesn't matter, look on second parameter "message", without it we show defaulted message, i think about this feature by default told @jota, because as i said before, with typescript creating structs with custom errors, lool like "I just override all library in my app"