The thing is, unlike integrating Elm and a third party library, which requires Native Elm code or ports with Native JS glue, using a web component in an Elm application is conceptually/potentially/syntactically no different than using an input or button as you normally would in elm-html.
I think your concerns about the mechanics are correct and it's probably going to be non-trivial to integrate big web components, i.e. those with lots of state, with the virtual DOM. But keyed nodes are already a problem before we used web components - we already have local state redraw optimization problem if we have a large array of stateful DOM (such as regular input nodes). It seems like it should just work. (I haven't seen the 0.18 stuff though) I also posit that automatically generating a web component for every top-level Elm app is isomorphic and maybe even superior interface to our existing method of embedding Elm in native HTML pages, and could even increase adoption as we could publish web components written in Elm for consumption by anybody. Anyway, to lay down a synthesis of my thoughts: web components are the right abstraction to deal with this recent problem, it's a web standard, we do no harm by streamlining interoperability with non-Elm, and this whole thing can live external to the Elm toolchain until if or when the experiment proves successful. On Sep 21, 2016 1:14 PM, "Mark Hamburg" <mhamburg...@gmail.com> wrote: > 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 < > richard.t.feld...@gmail.com> wrote: > >> No problem! Hope it works well. :) >> >> On Tue, Sep 20, 2016 at 2:22 PM Peter Damoc <pda...@gmail.com> 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 < >>> richard.t.feld...@gmail.com> 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/po >>>> lymer.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 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 a topic in the >>> Google Groups "Elm Discuss" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>> pic/elm-discuss/2RTddO_4rLw/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> elm-discuss+unsubscr...@googlegroups.com. >>> 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 elm-discuss+unsubscr...@googlegroups.com. >> 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
