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/
>>>    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 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/
>> topic/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.

Reply via email to