Well said, John! Neatly sums up my thoughts on the matter. :) On Wed, Sep 21, 2016, 5:59 PM John Mayer <[email protected]> wrote:
> 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" <[email protected]> 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 < >> [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. >> > -- > 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.
