On Friday, October 7, 2016 at 8:08:43 AM UTC+1, Peter Damoc wrote: > > I was thinking more in terms of having a way to define custom components > in Elm and then use them in Elm while avoiding to duplicate the runtime and > the rest of the core libraries. :) >
Yes, so you can have internal state in the custom component that is not visible to the application using it. I was thinking that using the paper-listbox has not really saved me much - I am still dealing with select/deselect events and it has little internal state. I may as well write this purely in elm. On the other hand if I add more state to the component, such as a scroll bar and scroll state, or have it fetch the list of items from a picklist on the server itself, then I am getting to the point of having enough internal state that the user of the component does not care about in order to use it. I think I create my own custom polymer element around what I have so far, so that as a consumer of the component I just get notified of what the current selection list is, [ (1, "Bold"), (3, "Underline") ] for example, every time it changes. > This one, I think, is a polymer component implemented with elm: >> >> >> https://github.com/kevinlebrun/elm-polymer/tree/master/counter-elm-inside-polymer >> > How about taking this example, and using it as a polymer component within an elm application? So elm inside polymer inside elm. Sharing the code between the two elm parts, just with two separate mains. Yes, we just need web-components, not polymer. Polymer is prividing some convenience to experiment with web components though. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
