FormError lack of compatibility default api validation errors

Get Help and Help Others
1

Hi,
I am trying to group all backend validations into a single error object that is returned to the frontend so the user can know at once all they have to fix.

To do this I am trying to use RedwoodRecord since it already returns a nicely formatted output.

For example, with my current contact model from the tutorial I am getting this error output:

{ 
  base: [],
  name: [],
  email: [ 'email must be formatted like an email address' ],
  message: []
}

and then what I am doing with that output is:

throw new UserInputError("Can't create new Contact", {
  messages: contact.errors,
})

First issue I encountered with this structure is that when passing the error object to the Form component it marks all fields as with errors because it receives an empty array instead of undefine I assume. This is easily fixable.

The second issue that I am getting and it’s mainly why I am creating this topic is the following:
The FormError component when getting a structure like that lists the field errors in a list and prefixes the errors with the name of the field, the key in the object. Why is this a problem? In the Blog tutorial the error is created manually and does not include the name of the field already. But both the validate default messages and the RedwoodRecord validation errors include the name of the field already so I am getting the following error message displayed:

Can't create new Contact

email email must be formatted like an email address

So my question is, why does the FormError add as a prefix the name of the field? Shouldn’t that be handled in the api? the api should provide user ready errors. Specially if the intention is that in the future a project can have multiple frontends.
And as I already mentioned this is kind of already being handled by the api anyways so that’s why I get the double name of the field at the begining.

When using validate from the api lib I am not getting this error but this is just because it throws an error on a per-field basis so once a field is invalid it returns a single error not with the structure I showed.
I assume that if I put a try-catch for each validation and agregate them with that structure, the same would happen.

I can work on fixing the issue with the empty arrays being marked as errors but would love some more discussion around the other issue before starting to implement anything since I see backwards compatibility issue with just removing the field name prefix on FormError

2

Maybe we can add a boolean prop to FormError that decides if it prefixes those errors with the field name and default it to the current behavior so there are no breaking changes.

I remember a similar feature in validate.js a client side validation lib that you could pass the option fullMessages: false if you didn’t want the lib to append the field name.

3

Yeah, sorry about that. We’ve got an ongoing issue here: https://github.com/redwoodjs/redwood/issues/4371

When I first built the form helpers we had no build-in validation, so it was up to you to just throw an error in a certain format and then the error handling in the form helpers would pull it apart, show all the messages at the top of the form in <FormError> and then the individual fields would be highlighted with their own error messages.

A year later I added Service Validations and for some reason completely forgot about the form helper stuff. So the shape of the error there isn’t matching the shape that <FormError> expects so the fields aren’t highlighted any more. :frowning:

So basically if you use Service Validations (or the validate() function in RedwoodRecord), which should simplify errors shown in forms, actually makes them worse. That Issue hasn’t had any updates in a week, I’m not sure what the current status is.

4

Personally I prefer to just return error codes from the API and handle all messaging on the front-end. But I think I’m in a minority here. So that’s probably not something that’s going to happen now.

@dthyresson Any updates on that issue you’re working on that Rob linked?

5

I have a solution but it requires tightly mapping a form field name in the api which isn’t ideally but essentially how it worked before.

I’ll try to finish it this week - I just need to check with the team that’s the approach everyone agrees on.

Id like to add that field error for GraphQL scalar validations too — but in their case, it always knows the input name so no need to do it in the service

Note: for v2 I want to do it a little differently

6

Oh thanks, I’ll keep an eye on that GH issue