1. Honestly, I'm unsure a new program type is needed. The big encapsulation of webcomponents are their properties and attributes. Listening to a property/attribute change internally is as simple as getting a message (via subscriptions no doubt) on their change via the Observer API (which Polymer hides behind the scenes for you). Setting external attributes and properties can be as simple as sending a command, although in my opinion the top-level 'view' element should expose it that way, both properties and attributes can be done that way and much more succinctly, but that 'might' necessitate a program change to take an enhanced view function.
2. Polymer is just a library to make writing webcomponents in Javascript a bit easier, entirely unnecessary for an Elm integration and if you follow the HTML5 standards and events (Polymer does standardize a few event names that you might want to duplicate for ease of use, but that is really optional). A webcomponent is only the javascript parts. The reason you use some DOM, the <dom-module/> and <template/> parts is just to ease the making of the DOM in the webcomponent, this part is entirely unnecessary in Elm and that removes the major using point for Polymer, the raw webcomponents API is far more simple (though usually more wordy than what you could make in Polymer, hence why Polymer is useful for javascript, but elm already has a good virtual-dom). 3. Trivial to do as using them would be just like using normal DOM node's, which you can easily use in Elm already. However, Elm does need to register observation events on those elements to listen to the backwards flow of 2-way data binding, this is an absolute necessity. 4. You also need multiple 'main' functions, probably named the same as the webcomponent name it creates. :-) Elm could definitely become a fantastic webcomponent library. :-) On Thursday, November 10, 2016 at 4:11:14 AM UTC-7, Rupert Smith wrote: > > On Wednesday, November 9, 2016 at 4:02:42 PM UTC, OvermindDL1 wrote: > > In my opinion Elm really needs to have a smooth integration with > webcomponents. A webcomponent is a very small unit, something elm > > fits fantastically in, has two way data-binding up/down the DOM stack, > and getting built-in to browsers (Chrome is about the only one with > > near-full support though, but it is coming in others). It is something > that Elm would fit fantastically in if we could somehow get information > > *out* of a webcomponent, right now elm can only put information 'in'. A > binding to the HTML5 Observer API being transformed into Elm > > Messages would be about perfect. > > After experimenting with Elm and Polymer I came to these conclusions on > future directions for this effort: > > 1. Build some support into the Elm compiler for webcomponents. This would > be a new 'program' type with support for hooking parts of the program state > and events up to a webcomponent. The consuming program would also be able > to link to it, in such a way that it can be given access to its 'public' > state. This is really OO encapsulation, and as such might not be a popular > idea within Elm. I only have a vague idea of what tighter integration would > look like anyway, so far too early to start down this route. > > 2. Build a component library using Elm + minimal amount of Polymer. > > 3. Build components on top of polymer-paper elements in the MDL style. > > This thread is about exploring option 1 in further detail, what would an > Elm with webcomponents integration built in to the language/framework look > like? I'll think about it and see if I can come back with some suggestions > or sketch out a bit in pseudo code what it might look like. > -- 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.
