search

guardian / typerighter

Even if you’re the right typer, couldn’t hurt to use Typerighter!
Apache License 2.0
276 stars 12 forks source link

Make FormError keys machine-readable rather than user facing #397

Closed Fweddi closed 1 year ago

Fweddi commented 1 year ago

What does this change?

At the moment, we have FormError objects we send back to the client on publication validation failures. Both key and message are human readable.

This PR treats the key as an error id (e. field-missing). Only the message should be human readable. This applies whenever we’re passing FormError events back to the client.

How to test

Have a play around with the form on the client and see if the form error IDs make sense.

Tests should pass.

We shouldn't lose necessary error context in this change.

Fweddi commented 1 year ago

I suppose it depends on how tightly we think the field should associated with the key. I'd argue in this PR there is still a strong association between the key and the field name?

rhystmills commented 1 year ago

I think the idea is that - if the error key and the field name exactly match, you can used the error key from the backend as an identifier for the field in the frontend, then match them up in the frontend to show a field's error directly against the relevant field. However, we're not doing that, and the error messages provided were not very useful when I tried this, plus we have our own inline validation in the client anyway. If we did want to do this, it would just require a minimal transformation from this PR (i.e. remove the "invalid-",