update school validations to return list of errors for frontend use

[conorriches]

Issue

Related to https://github.com/RaspberryPiFoundation/editor-standalone/issues/28

What changed

When a school is trying to be created, but validations fail, we now get this response:

{
  "errors": {
    "website":["can't be blank"],
    "address_line_1":["can't be blank"],
    "municipality":["can't be blank"],
    "country_code":["can't be blank","is not included in the list"]
  }
}

This is useful, as the FE application can now iterate on the keys, and selectively update each input field to show the error message.

Before this change we got:

{"error":"Error creating school: Website can't be blank,Address line 1 can't be blank,Municipality can't be blank,Country code can't be blank,Country code is not included in the list"}

which isn't useful, as we can't associate errors to fields

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have you on file. In order for us to review and merge your code, please complete this form and we'll get you added and review your contribution as soon as possible.

[sra405]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[danhalson]

Looks great :)

[danhalson]

perfect!

[chrislo]

@conorriches have we thought about the i18n story around these error messages? I notice we do try to translate/localise strings that appear in editor-standalone, but I'm not sure how that would work here. I can think of two approaches off the top of my head 1) pass a language parameter in API requests so the API can return the correct version of the strings, or 2) return an identifier for each error instead of a string and use that to look up the localisation on the client side.

I'm also slightly nervous that we're relying on the keys (e.g. website) staying in sync between client and server. Have you thought about how to make sure they don't drift apart?

[chrislo]

@conorriches - I should say I don't think these queries are caused by things you've introduced in this PR, I think we had the same two issues with the previous approach. I guess I'm mostly interested in having a cross-team approach to them to make sure we keep things consistent.

[conorriches]

Hey @chrislo - yeah indeed a good thought, my running assumption was to keep the i18n on the frontend side of things, as we already have i18n set up there, and I was mostly relying on the backend just providing a list of fields that need flagging.

But it's a good point and I think we should look at i18n more broadly, specifically about how we want the api to respond to locales. The error messages appear to be coming out of rails itself, so passing in a locale and having i18n translations would probably be the best approach if we do want the api to be aware of i18n.

I've asked in slack about whether we will need locales - but so far in the frontend we only have the en locale, though if we plan to have full i18n support it would be good to define the boundaries for which side the translations will live on.

I'd like to understand more the concerns about keys staying in sync - the reason I felt safe doing this is that if they keys do go out of sync, then the endpoint won't be able to process the form properly as fields will be missing, meaning the form won't submit even without validation messages.

[conorriches]

Discussed on Slack and we have captured the requirement in #272