This is a great question! I think there's a very clear answer here:
*Don't overengineer it.*
As you noted, this is basic - *super* basic - so by default, the best
solution is also super basic.
There's a button with 2 configurable options? Cool, let's write a function
that accepts that configuration and returns the button we need:
fancyButton : { label : String, icon : String } -> Html msg
fancyButton { label, icon } =
-- Implementation goes here
Done!
In a language where refactoring is nice, you can and should reach for
simple solutions when the problem is simple.
If the problem gets more complex later, you can then revise from a position
of knowledge: you'll know *precisely how *it's more complicated, and that
gives you the information you need to end up with the nicest API possible.
Conversely, trying to design an API to fit nebulous theoretical future use
cases essentially means going in blind, and it's a recipe for unnecessary
suffering in Elm. :)
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
