Extra fields errors

[dakujem]

I'm using a strict server validation and what happens is on extra field, there is no visual feedback and to process the error is very laborous.

Example setup:

1. the form has fields anomaly, boom, cone,
2. the server only accepts boom and cone
3. the submission error handler is similar to this:

   errorsFromServer.forEach(
     (v) => actions.setFieldError(v.source, v.message)
   )
   

The problem is that the v.source is equal to anomaly and thus the error message ("Extra field anomaly present in the request.") is NOT shown anywhere.

The ideal solution would be the ability to set a callback that would process the unprocessed errors.
I don't have enough knowledge to say how that fits with VeeValidate, unfortunatelly. I'd assume the setter (and potentially the getter too) would be part of the actions object, something like actions.setUnprocessedErrorHandler(myHandlerForUnprocessedErrors).
I reported the same issue with Formkit and it was one of 3 reasons why we're considering moving away from Formkit, and here I am testing VeeValidate, to be honest.

Of course I understand that a userland solution would be to check for the unprocessed error messages (extra fields) manually, but for nested forms with repeating parts this becomes extremly tedious and the support on the library side would help considerably.

[Vue v3, VeeValidate v4.x]

[logaretm]

I converted this to a discussion because it doesn't seem like an issue report.

Interesting use-case. But I would like to understand more.

How would the state reach that point? As how would the user end up sending incorrect input or extra input to the API through the UI? How do you expect them to correct that mistake if you show the error?

For example, I'm a user who can see 3 fields at the moment. boom and cone and anomaly. I fill them and I get error messages on my UI. One of them says "Extra field anomaly present in the request.". What do I do now as a user?

To me, it sounds like client-side UI and validation should've caught this and prevented presenting and sending a non-valid request in this case. I also work with very strict server and GraphQL schemas with nested structures with a lot of oneOf input that is similar to this. But I would like to understand more about your use case before I can say more.

[dakujem]

How would the state reach that point? As how would the user end up sending incorrect input or extra input to the API through the UI?

Quite easily in fact: by setting the initial values. For example, the JS app loads a model from the backend with an id and then sends it back, but the PATCH endpoint refuses to accept changes to the id (in general, the backend might not accept changes to all the props it exposes to the clients).

How do you expect them to correct that mistake if you show the error?

I don't. But I want the handler to log the issue and let the user know there is an issue with the form that needs to be fixed.

I fully agree that a front-end validation SHOULD catch issues like this. But I also work in the field and know that mistakes do happen. In this case, the server simply throws 422 response because it does not accept the request due to validation issues, but since it's a client-side error, it does not trigger error alerts. On the other hand, this is a big problem on the client side, because as a result, the client is unable to submit a form and no developer gets notified.
I want to specifically notify the developers of the client, because they SHLOUD have caught the error, but have not.

I converted this to a discussion because it doesn't seem like an issue report.

Sorry, I'm not fully used to this GH feature yet. I just wanted to get in touch somehow.

[dakujem]

Currently it is tedious to filter through the validation errors and see if the source of the issue is not a filed that does not exist. For more dynamic forms I'm not sure how I'd even do it.

I don't know how the handling is implemented in VeeValidate, but if there already is a function that tells it that the input does not exist, exposing it might just be what is needed. In the error handler, I could simply ask VeeValidate if it recognizes the input, and handle the issue if it does not.
Something along these lines:

errorsFromServer.forEach(
  (v) => actions.inputExists(v.source) ? actions.setFieldError(v.source, v.message) : logThisIssue(v)
)