Easy format errors like in Zod?
Hi, I can't find any errors formatting like in zod. https://zod.dev/ERROR_HANDLING?id=formatting-errors.
I'm doing it manually now, maybe I'm missing something?)
19 Replies
Are you just looking to have errors by field?
Yeah, that's what I mean.)
There is a
byPath prop on ArkErrorsYeah, I've seen it and I've watched it. But it's not quite the same. I often need this format for api response
errors: {
email: ['invalid email, 'spam mailbox']
}What specifically are you looking for about that response?
I need to show validation errors under each input. I'm just saying that I need to go through the object, pull out the error text and compose it into an array. Zod has a built-in method for this. I think this is a common use case, no?
I don't know what the parts of the array
email: ['invalid email, 'spam mailbox'] are supposed to represent in this case
byPath is very deeply introspectable. You can discriminate the error kind with hasCode()I just gave an example above, it is not about the error text itself, but about the format.
I need write this code to format errors like in zod to get this
{
email: [ 'email must be an email address (was "")' ],
message: [ 'message must be non-empty' ],
name: [ 'name must be non-empty' ]
}
if (data instanceof type.errors) {
const formattedErrors: Record<string, string[]> = {};
for (const problem of data.issues) {
const field = problem.path.stringify();
if (!formattedErrors[field]) {
formattedErrors[field] = [];
}
formattedErrors[field].push(problem.message);
}
console.dir(formattedErrors)
}Ah okay you just want an array even if it's just a single error. ArkType collapses mutliple errors at the same path to an intersection error.
It would be easier to just map from
byPath and check if the code is "intersection".
I can add an errors key or similar as a convenience that would just be [this] for errors other than intersection. Then you'd just map it to the raw messages if that's what you need (although also stringifying the error objects directly yields the message)i can use errors but
Property 'errors' does not exist on type 'ArkError<ArkErrorCode>' is that what you're talking about?Check
e.hasCode("intersection") ? e.errors : [e] to flatten
I will probably publish a new version this morning with this built-incool, thank you)
Probably will look like this
looks cool!. Can the second method be added just in case, like flatMessageByPath?
You mean with the message including the path context? It seems like if you've already sorted errors into paths having them include the location would be redundant
The only difference between
problem and message is message includes a description of the path like at myKeyYes I realize that, but it can be necessary and valid, as an example in laravel https://laravel.com/docs/12.x/validation#validation-error-response-format.
Validation - Laravel 12.x - The PHP Framework For Web Artisans
Laravel is a PHP web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.
Hmm, interesting. Well I don't think that's a good standalone error format, so I'll probably just ship the problems variant and the generic
flatByPath and you can map easily enough with Object.fromEntries:
Yes, I think you're right, there is no one-size-fits-all option) I'm just speculating based on other examples
Hopefully the base version of it is easy to adapt, and I think the
problems variant is the most generally sensible format to reduce it down to strings without redundant info