Validation should return multiple errors instead of throwing a single one about valibot HOT 22 CLOSED

Valibot already does that. I use it myself in my own form library Modular Forms.

from valibot.

I have now decided to collect all issues by default. This behavior can be controlled via abortEarly and abortPipeEarly if needed. Thank you all for contributing to this feature! More about this here: https://valibot.dev/guides/parse-data/#abort-early

from valibot.

I think he's talking about displaying all errors when a form contains several incorrect fields.

e.g. a form that contains username and password fields which are invalid, the parse function should return that username AND password are invalid and not only username

from valibot.

That's awesome, releasing the vee-validate integration soon once I work on the docs.

from valibot.

I reopened the issue @fabian-hiller @logaretm and yes, that's what I meant

from valibot.

and thank you for your work and time @fabian-hiller

from valibot.

Later I will share the changes with you and publish a new version.

from valibot.

Great! Feel free to add vee-validate to our ecosystem page then: https://valibot.dev/guides/ecosystem/

from valibot.

Can you explain a bit more, preferably with a code example, what exactly you mean? Is it about the transformation and validation pipeline? Do you know how other libraries, e.g. Zod, handle this?

from valibot.

Hey, sorry for jumping in here but seems relevant. I'm currently playing around with valibot support for vee-validate (for Vue.js) and encountered a similar situation.

Given a schema like this:

const schema = string([email(), minLength(8)]);
const result = await safeParseAsync(schema, 'hello@');

console.log(result.error.issues.map(issue => issue.message)); // [ 'Invalid email' ]
// expected?  [ 'Invalid email' , 'Invalid length']

At the moment only the leading validator error is being generated, in this case, email error is the only one. Is that a design choice for valibot at the moment? Both yup and zod allow this by adding a configuration like abort or a similarly named option to the parse method.

Personally, I don't have an opinion here, but when working with forms, some devs expect to be able to show multiple error messages per field. If this is a welcome addition, I may try to PR it.

from valibot.

@logaretm here I am not quite sure myself yet. But technically it is possible. For now, just create an issue with different suggestions for the API. Then we look together further.

from valibot.

@fabian-hiller What do you think of something like this:

Adding PipeExecutionOpts interface that will be added as an optional additional argument to all schemas .parse methods and parse/safeParse functions. Something similar to this:

/**
 * Configures how a pipe should be executed.
 */
export interface PipeExecutionOptions {
  abortEarly?: boolean;
}

And then the API would look something like this:

const schema = string([email(), minLength(8)]);

// Should throw a ValiError with two issues instead of one
parse(schema, 'hello@', { abortEarly: false })

I got a quick PoC working with tests for a few schemas, if this is a good direction I would be happy to continue and PR it.

from valibot.

@logaretm thanks a lot for your research! I had completely different thoughts before and find your approach, where this behavior can be controlled via the parse method, better. Do you have alternative name ideas to abortEarly?

from valibot.

@fabian-hiller Thanks. I don't really like true boolean defaults so I tried to think of the opposites but they aren't any better.

Here are a few alternative names I thought of.

If the default is true: aborts, bails, exitEarly, exits, skip or any of the previous with ___onFirstError.
If the default is false: accumulate? Not sure really.

Let me know if I should keep going once we figure out a better name.

from valibot.

Does Zod or any other schema library have this functionality? Does anyone know what it is named there?

Thanks for your ideas, there are interesting names there. The name basically has to describe that per primitive value, if the option is set, more than one issue can be thrown or that not after the first error the pipeline is aborted.

Here are ideas I came up with: abortPipe, abortFirstError, firstErrorOnly, onlyFirstError, entirePipe, noAbort, forcePipe.

Although I haven't decided yet, I find e.g. forcePipe an exciting name as an alternative, as this automatically makes it clear to the developer that the pipe is always fully executed, which might lead to unexpected behavior in some cases.

from valibot.

Does Zod or any other schema library have this functionality? Does anyone know what it is named there?

Thanks for your ideas, there are interesting names there. The name basically has to describe that per primitive value, if the option is set, more than one issue can be thrown or that not after the first error the pipeline is aborted.

Here are ideas I came up with: abortPipe, abortFirstError, firstErrorOnly, onlyFirstError, entirePipe, noAbort, forcePipe.

Although I haven't decided yet, I find e.g. forcePipe an exciting name as an alternative, as this automatically makes it clear to the developer that the pipe is always fully executed, which might lead to unexpected behavior in some cases.

Zod doesn't abort early by default but in superRefine function, we can return z.NEVER to indicate we want to abort early.

from valibot.

In Yup it is called abortEarly. In zod, AFAIK this is the default behavior like @Yovach mentioned.

forcePipe Sounds good to me as well. Happy to proceed with it.

from valibot.

Thank you very much for the info. Should it also become the default behavior at Valibot. 🤔

from valibot.

I think it is a matter of expectations. Do you think people using Valibot will expect this more than the other way around?

In forms or client-side use-case, I believe it is more common to display just 1 error for the user. But from a parsing/validation standpoint, like using it on a server. Then a complete pipe run may be desirable, but I'm not sure. Feels like an arbitrary decision.

What I can say is, this isn't a breaking change even if you change your mind. issues is always an array and whether it has one or multiple errors, developers will access it in the same way.

from valibot.

I find it more natural and also more useful if the library throws the first error of a schema. The first error is probably sufficient for most use cases. However, if we return all errors, only the first error can still be shown to the user in the end. Therefore, it seems to me that in practice it doesn't matter which way we choose. It probably only matters that the library is technically capable of outputting more than one error per schema function.

from valibot.

The ability to have all the errors at the same time is mandatory in my opinion. In a lot of cases we want to display all the form errors at the same time so the end user will not have to resubmit multiple times until the form is valid.

from valibot.

Thank you for your feedback. I will later examine a possible implementation based on @logaretm code.

from valibot.