Op zondag 4 december 2016 15:43:40 UTC+1 schreef Peter Damoc: > > You're trading one set of boilerplate for another. >
Fair enough. I could have pointed that out in the conclusions. Both your versions are almost as bad as you are forcing internal details of > the functioning of the dropdown onto the user of the dropdown. > Could you explain this? I am not sure I follow what you are saying here. Wouldn't we always enforce some kind of API from the dropdown on the user? Or what would need to be different in both versions to not "force internals .. onto the user" ? The pure version is indeed more aligned with the current recommendations > but it is almost as bad from a library user point of view. > Taking the pattern and consequences from a dropdown to a library is something that I did not consider. Maybe I should have. > In order to have a full treatment of the issue, implement a > webcomponents/polymer version of the same functionality and then argue that > the "pure" version is better. > By no means did I intend to make a full treatment of the issue, or claim that pure is always better than stateful. Admittedly, the wording of the last paragraphs was too strong, so I changed that. I follow the uptake of integrating web components/ polymer with much interest. The argument in the article was made specifically where the dev is building everything in elm, and wants to structure his/her code when the app grows. The implementation of a Polymer version is a different scenario IMHO. But thank you for the challenge, I'll look into it ;) -- 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.
