Rethink how `null` values are handled

[hannalaakso]

User should be able to submit a form with autocomplete with a null value because they're being presented with a text box (the UI itself doesn't suggest it is a select) and text boxes natively allow you to submit a null value on the client side (thanks @joelanman!).

We should add to guidance that select should always have <option value=""></option> to ensure that even if user is getting the native select experience, they can still submit a null value.

Handling of null values should be the concern of server side validation.

The guidance here needs to be rethought: https://github.com/alphagov/accessible-autocomplete#null-options

We should consider injecting a null value into a select if we detect it doesn't contain one.

We could also consider adding some optional client side validation (eg. if user opens autocomplete but doesn't select a value, show error message). However this could be a lot of work and wouldn't necessarily fit in with other client side validation the service might already have in place.

Linked to:
#220
#236
#205

[HughePaul]

for a select box with enhancement: If text was entered that didn't match any results and that was submitted, i'd expect the field to behave as if no item had been selected, and normal form validation should handle that in the same way it would for a normal select box.
Otherwise the user doesn't know what they have submitted

[edwardhorsford]

Although the autocomplete progressively enhances a select, it could replace it with a input - which is what it looks like anyway. Then the input can submit whatever inputs are allowed to submit. If the response has to be one of a set values, the autocomplete can already handle clearing entries that don't match.

I don't see why we'd need to have selects with null values - the only reason we have it is because that's how inputs work. If it doesn't look like an input we don't need to make it behave like one.

[HughePaul]

submitting the non-matching query value (as a text input) would be better than submitting a previously selected (or default) item that the user can no longer see. then server side validation could complain.

[nubz]

Yes I agree @HughePaul - clearing the input gives the illusion to the user that you have now emptied it, but we can see under the hood the select still has the previously selected item still selected and going into the payload - this is particularly important on optional fields where an empty string is a valid response, it is not possible to select an empty string after selecting a matching option without fixing this bug on handleInputChange which simply sets the state to options: [] for exmpty queries and does not reset the select element to it's default value (which I think is the expected behaviour)