alex35mil
commented
2 years ago Hey @lozlow, thanks for pointing this out. Actually, this is intended behavior. Here's the reasoning behind this decision.
When a server responds with an error, such error contains information that the client doesn't have. This information might be required for a user to address this error. But if the server error is stored in the client's state and treated as a generic validation result, in this case, these data would be erased on the next keystroke in the field and replaced with a valid state since the client considers this form valid. re-formality can't make assumptions about the nature of such errors and how developers want to treat them. E.g., is this error expected? Or does this happen due to a bug in client/server validators that caused a mismatch? Is it ok to replace it with the client validation result? Or should it be persistent in UI until the next submission attempt? Etc. So, for now, I choose the less destructive way: let developers decide how to handle such errors in UI as they are on the application side of things.
Let me know if that makes sense.
Our API validates requests as a whole using JSON schema and returns a list of issues that we would like to update the form state with. The schema includes more business-logic aspects that we wouldn't want to encode into the validators of the frontend. It would be very helpful if we could set the validation errors for each field in the form inside the submission callback. I'd be happy to contribute the change if you thought agreed with the approach, what do you think?