Adding validation results after form submit

[DovydasNavickas]

Validation can be done during form submit by the server. We send the resulting form object to the server, JSON schema or schema validator, e.g. yup library. In case of an error, we need to display the error (well, doh).

The easiest way to get this done is to add an error to the form itself, but it will not be contextual. At best it will have one or multiple fields mentioned in the error message, but it can still be better.

In case we have errors for specific fields, we need to add them into specific fields states.

At the moment we've added validation property into the main state of the field, because all fields can be validated.

The structure for validation object as of now is:

interface FieldValidation<TValue> {
    results: ReadonlyArray<ValidationResult>;
    validators?: ReadonlyArray<FieldValidator<TValue>>;
}

In previous versions of the library, we used to have either errors coming out of validation or nothing, meaning everything's fine. But there were times we needed to only warn the user and not bail out with an error and we couldn't.

That is why we're introducing warnings in addition to errors in the current version.

Thus, instead of having the errors array as we did before, both errors and warnings go into the results array on the validation property of the FieldState.

(Un)Fortunately there are a few new problems and/or opportunities with this approach.
In case of an error, we could simply bail out, because we were sure the value was incorrect and that's why we could have a single error.

But with the introduction of warnings, should we bail out on the first warning? Doesn't seem right. The warning only warns about something, but does not mean the value is incorrect.

Ok then, we run validators until we encounter an error, right? Well... This means we might have several warnings and one error. Then user corrects the error and.... Gets the same warnings and another error.

Depending on your use case, this might be a behavior you want. But you might also want to run all validators and aggregate all warnings and all errors at once, informing your user on all of the problems that need to be addressed.

Thus, we have multiple approaches for the validation:

1. Run validators until all are run or the error is encountered.
2. Run validators until all are run and aggregate all warnings and all errors along the way.
3. Run validators until the first warning is encountered.

Let's get the 3rd approach out of the way, as I think it's plain wrong. The warning is, well, a warning, not an error. This means it shouldn't stop you, just inform you that something is worth your attention. E.g. you are approaching your quota of something and you might want to order more of the stuff. Does this mean your data is incorrect? Not at all.

Thus, we're left with two other options.

As mentioned above, the 1st one might be something you want, depending on your audience. But you might also want the 2nd one. Thus, I think the best way out here is to give the developer an ability to choose, selecting one as a default one. And I'm rooting for the 1st one as a default one.