Web components may be a reasonable answer with the following caveats: 1. Getting these to work well for stateful components presumably relies on the virtual DOM code playing nice with DOM node lifetimes. The new version of keyed support in 0.18 may make this somewhat more difficult since it then requires putting keys on all of the peers to a DOM node that needs lifetime continuity.
2. As raised by one of my co-workers: If we tell developers to go write web components in JavaScript, don't we then risk them deciding that it's just easier to stay in JavaScript? A variant of this is that one of the arguments made by Evan for being conservative about bridging to existing JavaScript libraries is that Elm code is better and hence we want to encourage people to write Elm wherever possible. This is a push back in the other direction. The second point has to do with whether it's better to have people writing Elm code or JavaScript and if Elm is better what needs to be done to avoid pushing people to JavaScript. Where is the line between "don't get blocked" and "go somewhere else"? The first point basically has to do with confronting the fundamental nature of virtual DOM systems, particularly those in pure functional languages. In any system where we explicitly create objects — including React — then there are generally ways to attach private state to those objects because they have a continuity of identity provided by their creation. But when we go to a pure functional language, we expect to be able to just regenerate the view tree as often as we want and any continuity between nodes needs to somehow be manifested in the tree. This means that we need to either manage and provide identifiers for the view nodes so that the virtual DOM update logic can establish the right correspondences or we need to explicitly manage the local state ourselves. That seems pretty much fundamental and the question then to ask is whether we want to go the identifiers route as used by Elm parts and as probably needed for web components in the general case or whether we should establish a pattern for managing local state for view hierarchy elements. The latter is almost certainly more code but it seems like it more rapidly opens up the possibility of writing more new UI elements in Elm rather than in JavaScript. Coding patterns matter because they create conventions that everyone can play by, libraries can optimize for, and tools can exploit and support. Mark On Tue, Sep 20, 2016 at 2:28 PM, Richard Feldman < [email protected]> wrote: > No problem! Hope it works well. :) > > On Tue, Sep 20, 2016 at 2:22 PM Peter Damoc <[email protected]> wrote: > >> Hmm... I tried integrating the icon-toggle-demo and, to my surprise, I >> got it working even if it's past midnight here and I'm dead tired. >> >> I need to explore this some more tomorrow. >> >> Thanks Richard! >> >> >> >> On Tue, Sep 20, 2016 at 7:24 PM, Richard Feldman < >> [email protected]> wrote: >> >>> If nothing is wrong with Web Components, why not use them? >>>>>>> >>>>>> >>>>> There are a ton of them >>>>> <https://elements.polymer-project.org/browse?package=paper-elements> >>>>> you could use right now, for MDL in particular, that work right off the >>>>> shelf. >>>>> >>>>> >>>> You make it sound like it's a trivial thing for a beginner to integrate >>>> Polymer with Elm and hit the ground running. >>>> >>>> I seriously doubt that this is the case but I'll take another look at >>>> the projects that have attempted to do this. :) >>>> >>> >>> 1. npm install Polymer >>> 2. Add <link rel="import" href="/node_modules/Polymer/ >>> polymer.html"/> to your index.html >>> 3. Add this before the script that imports your elm.js: <script> >>> // register an element >>> MyElement = Polymer({is: 'my-element', >>> created: function() { this.textContent = 'My element!'; } >>> }); >>> </script> >>> 4. In your Elm code, run Html.node "my-element" [] [] >>> >>> I just tried this and it worked. :) >>> >> -- >>> >> 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. >>> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Elm Discuss" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/ >> topic/elm-discuss/2RTddO_4rLw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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. > -- 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.
