Currently the output of inputSelect (from digestive-functors-blaze) will look something like the following:
<select id="edition.country" name="edition.country">
<option value="edition.country.0" selected="selected"></option>
<option value="edition.country.1">United Kingdom</option>
The values here are only correct for as long as the country table is the same in the database. As soon as the ordering changes, those values are incorrect. In this case, the type of choices is Maybe (Ref Country), which is effectively Maybe String, so it's important to consider how Nothing would be represented.
Maybe (Ref Country)
I mainly just want to chime in with a "yeah this is a problem for me too". But I'll also add that this same problem affects radio inputs as well as selects.
After pondering on it for a while, I think I'll just go with the straightforward solution: extend the choice combinator so you can give it [(Text, a, v)] instead of just [(a, v)]. I'd call it choiceWith so we can keep the current version as well. Any objections/thoughts?
[(Text, a, v)]
Partial switch to text labels for choice (WIP)
Bump all the things, use new choice structure
Note that the user will still have to submit edition.country.uk instead of just uk, I hope this does not form a problem for your use case.
Sorry, while it's close I don't think that is a solution. It does fix the race condition at least, but it doesn't open up options for people who want to submit the form from outside a browser, nor does it help port some legacy non-Haskell applications to Haskell land because the API has changed.
Ironically, I was mistaken and this already works because of the way I coded the form evaluation.
The only restriction seems to be that the labels cannot contain a dot character.
Add experimental choiceWith and a test