mdgriffith / elm-ui

What if you never had to write CSS again?
https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/
BSD 3-Clause "New" or "Revised" License
1.35k stars 110 forks source link

Record fields order #288

Open pravdomil opened 3 years ago

pravdomil commented 3 years ago

Input.radio is defined like so:

radio :
    List (Attribute msg)
    ->
        { onChange : option -> msg
        , options : List (Option option msg)
        , selected : Maybe option
        , label : Label msg
        }
    -> Element msg

When I think about radio buttons I define label first, then list of options, then which option is selected and then what happen if you change option. Like so:

radio :
    List (Attribute msg)
    ->
        { label : Label msg
        , options : List (Option option msg)
        , selected : Maybe option
        , onChange : option -> msg
        }
    -> Element msg

To save time I copy function type annotation from elm-ui source to my code and then I run elm-format that changes : to =, and then I fill in the values, and that forces me to think about onChange value first and label value last. I think that it should be other way around. It also is more natural as time goes by first label is printed, then options are printed (with selected one) and then something happened and option gets changed.

This is related to other places as well radioRow, text, multiline... Maybe even Element.link which is now { url, label } and for example in markdown it is [label](url) or Element.image.

What do you think?