We have many places in our code base where we need to sort strings to be displayed in the UI, which we normally do by calling either compare, List.sort or List.sortBy. All of these functions will sort strings in a case sensitive manner though, which is rarely what we want. That is, sorting a list of strings ala [ "a", "c", "B" ] will give [ "B", "a", "c" ] when we really want [ "a", "B", "c" ].
The simplest fix for this is to remember to always call String.toLower in the appropriate places before sorting, but this has proven untenable in the long run for our big code base with many developers on it. We're now starting to ban calling compare directly using elm-review and only allowing wrappers which force you to explicitly choose the ordering you want (e.g. compareStringsIgnoreCasing and compareStringsWithCasing). This works, but also has downsides, like how we can't have those wrappers take comparable arguments, but only String, so now must tighten our types in places that could previously use comparable types to be String for example.
All in all, the current API doesn't feel like it has any good solutions for this.
We have many places in our code base where we need to sort strings to be displayed in the UI, which we normally do by calling either
compare
,List.sort
orList.sortBy
. All of these functions will sort strings in a case sensitive manner though, which is rarely what we want. That is, sorting a list of strings ala[ "a", "c", "B" ]
will give[ "B", "a", "c" ]
when we really want[ "a", "B", "c" ]
.The simplest fix for this is to remember to always call
String.toLower
in the appropriate places before sorting, but this has proven untenable in the long run for our big code base with many developers on it. We're now starting to ban callingcompare
directly usingelm-review
and only allowing wrappers which force you to explicitly choose the ordering you want (e.g.compareStringsIgnoreCasing
andcompareStringsWithCasing
). This works, but also has downsides, like how we can't have those wrappers takecomparable
arguments, but onlyString
, so now must tighten our types in places that could previously usecomparable
types to beString
for example.All in all, the current API doesn't feel like it has any good solutions for this.