Usage on frontend?

[jack-allocate]

I was looking at using this library on the frontend, and while it seems technically possible, I'm wondering if it's advised? Or is this a tool that in future updates will be more geared towards backend services that don't need to worry about package sizes?

The way the error messages are currently formatted (developer friendly but not user friendly) made me realize this.

[ssalbdivad]

The goal of our error messages is to be as user-friendly as possible. Is there a particular error message you feel is inappropriate for an end-user?

It's true that bundle-size is not optimal at the moment, but we do have a plan to address this via a build step where needed:

#810

[jack-allocate]

Thanks for the quick response! Love this library, it's really awesome.

Here's some examples of non user-friendly messages:
"date must be a string (was object)"
"regex must be matched by @gmail.com (was "[email protected]")"
"num must be a number (was string)"

These all use verbiage that only developers know - string, object, regex, number.

While I can't think of a better way to name these myself, it just made me think initially that this wasn't geared towards the frontend. I think they're definitely passable, and I see the error provides more information so that I could build the error myself.

It's true that bundle-size is not optimal at the moment, but we do have a plan to address this via a build step where needed:
Awesome to hear!

[ssalbdivad]

There are a few ways to add custom error messages. E.g. you could write:

const gmailAddress = type(/^.*@gmail\.com/).describe("a valid gmail address")

const user = type({
	email: gmailAddress,
	name: "string"
})

That said, most built-in keywords like email do have user-friendly messages like must be a valid email address. This kind of user-facing feedback would generally be seen in form responses, which should almost never have mismatched data types.

Once you get into errors like getting an object instead of a string, as you said there's really not a way to describe that without relying on some dev knowledge.

[jack-allocate]

Fair enough! thanks for the responses. We're gonna give this a try and see how it goes