Wouter,

After I found out about elm-polymer library, I tried to reimplement your
example but, I've run into issues.

This is as far as I got
https://github.com/pdamoc/polymer-exploration

The problems are due to the way children are handled.
I tried a fix that I remembered from a previous exploration (lazyRegister)
but, the rendering is still bad.

This is yet another reason I think that Polymer might not be the best way
forward.
A native Elm solution to Web Components might produce better results both
in therms of developer UX and in terms of final deliverables.


On Sun, Dec 4, 2016 at 5:51 PM, Wouter In t Velt <wouter.intv...@gmail.com>
wrote:

> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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.

Reply via email to