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.
