Validation errors difficult to match to form inputs

[s-taylor]

Apologies as I should have thought of this earlier when discussing #169 but would it also make sense to include an array of errors per field? This would be very useful in trying to map these back to form fields when there's been a validation error. Else we have to parse a comma separated string which is going to be flakey. Like...

{
    [fieldname1]: [errorMessage1, errorMessage2]
    [fieldname2]: [errorMessage3]
}

[kaievns]

@s-taylor we could, why not? the only concern i have here is the immediate usefulness of the HTTP response. i think it should have the full human readable message in it by default, visible straight away.

how about we put the object data as a piece of JSON into HTTP headers? it is a bit unorthodox, but would decouple the errors metadata from formatted responses (which could vary eventually)

another option is to just parse the response text. i've kept all the messages consistently formatted like so:

"`${key}` ${message},"

considering that messages are autogenerated, you should be able to extract the data with a simple regexp

[s-taylor]

Happy to opt for parsing, but is comma going to work if the message contained a comma or is that not a thing?

[kaievns]

i reckon you could look for another backtick or something like

/`(.+?)`\s+(.+?)(?($|, `))/g

[kaievns]

or split the whole thing by:

/(^|, )`/

first and then cut out the rest from each of them

[s-taylor]

cool i'll give that a shot

[kaievns]

hey @s-taylor do you still need us to add like raw validation data in headers or you're good with parsing the data from the error field?