Re: [elm-discuss] Elm, Objects and Components

[Richard Feldman]

Mark, this seems worth a separate thread. Would you mind opening one that
explains a couple of motivating problem scenarios, and then this proposed
solution?

On Sat, Sep 24, 2016, 5:28 PM Mark Hamburg  wrote:

> I wonder if the following strategy would work to address this...
>
> 1. Bring back some form of general purpose keyed identifier for virtual
> DOM nodes.
>
> 2. Before diffing two virtual DOM trees, build a map from keys to DOM
> nodes for such keyed nodes. When processing a reference to a node in the
> result, if it has a key, prefer to use the entry in this map. (Multiple
> uses of the same id need to have some logic to keep things from blowing up
> but we could reasonably lose the optimization for all but the "first" use
> of an id.)
>
> Challenges:
>
> * Will this actually work well with the real DOM or will removal and
> reinsertion cause problems?
>
> * This is essentially based on doing full scans of the tree and I assume
> there are optimizations around subtrees that haven't changed. Those
> subtrees would at least need to be scanned to continue their claim on DOM
> nodes with identifiers.
>
> But if this works, then the fix for a text node or web component getting
> its state whacked would be to give it an identifier.
>
> For lists, the new keyed support is great and probably more efficient than
> what we had before. But for creating "identity" for view nodes, it probably
> isn't what is needed and what was there before while better was not really
> fully sufficient either.
>
> Mark
>
> P.S. There is also a related problem for external components with not
> getting new components when we want them. Identifiers would fix that as
> well.
>
> P.P.S. This same work could also conceivably enable some form of DOM node
> recycling. I think I recall that being part of the set of tricks that
> Google Maps used to wow people on performance when it first launched and
> it's part of what Apple's UITableView does to get performance in native
> lists.
>
> > On Sep 24, 2016, at 8:27 AM, Richard Feldman <
> richard.t.feld...@gmail.com> wrote:
> >
> > Yep, very true. I would love for there to be a better solution for text
> fields in particular.
> >
> > --
> > 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 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.

Re: [elm-discuss] Elm, Objects and Components

[Mark Hamburg]

On Sep 24, 2016, at 2:18 AM, Peter Damoc  wrote:
> 
>> On Sat, Sep 24, 2016 at 12:20 AM, Richard Feldman 
>>  wrote:
>> Got it.
>> 
>> Fair point, although to me this suggests that WCs are best suited for state 
>> you don't mind losing, e.g. for a ripple effect. :)
> 
> Some of the components might have a complex user interaction that also is 
> important. 
> For example, the date picker allows the user to switch to a different month 
> in the process of selecting the date. 
> If due to some other UI update the date picker is reverted to the default 
> date without reason, this ends up being a bad experience for the user. 
> 
> But this is an implementation detail. Maybe it can be solved at the 
> implementation level somehow through some JS trickery. 

Elm presumably already has this problem for text entry fields which when 
focused have a selection range or insertion point. One just gets lucky much of 
the time because the view tree doesn't change. But one person's luck is another 
person's hours of hunting down a hard to reproduce bug.

Mark

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

Re: [elm-discuss] Elm, Objects and Components

[Peter Damoc]

On Sat, Sep 24, 2016 at 12:20 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> Got it.
>
> Fair point, although to me this suggests that WCs are best suited for
> state you don't mind losing, e.g. for a ripple effect. :)
>

Some of the components might have a complex user interaction that also is
important.
For example, the date picker allows the user to switch to a different month
in the process of selecting the date.
If due to some other UI update the date picker is reverted to the default
date without reason, this ends up being a bad experience for the user.

But this is an implementation detail. Maybe it can be solved at the
implementation level somehow through some JS trickery.





-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

Re: [elm-discuss] Elm, Objects and Components

[Mark Hamburg]

More bluntly, yes, Html.Keyed gives you the desired stability but only if
you use it for all nodes for which the sequence of children is not
fixed that could have a web component descendent.

Mark

On Friday, September 23, 2016, Mark Hamburg  wrote:

> Keyed expects all of the siblings to be keyed. This means that if you use
> one stateful (and since part of the point is that this is opaque, so you
> should probably assume stateful) web component in a list of siblings, you
> need to use keys keys on all of them.
>
> What's more that statefulness propagates up the tree. If you need to be
> protected from accidentally re-creating views at one level, you need that
> protection all the way up to the root.
>
> Each of these issues gets mitigated if the sequence of child views is
> fixed but without attention to the issue it's a lurking source of spurious
> bugs that the type system won't catch for you and that will instead require
> intensive testing to protect against.
>
> Mark
>
> On Thursday, September 22, 2016, Richard Feldman <
> richard.t.feld...@gmail.com
> > wrote:
>
>> I'm confused - Keyed is explicitly the solution to this...what is
>> insufficient about Keyed as a solution?
>>
>> On Thu, Sep 22, 2016 at 9:11 PM Mark Hamburg 
>> wrote:
>>
>>> The issue is that when you have external state, there need to be ways —
>>> features, patterns of coding, etc — that prevent accidental destruction of
>>> one component accompanied by creation of a new component when what one
>>> wanted was an update to the existing component. This depends on having a
>>> notion of identity that the HTML support in Elm eschews except for the
>>> keyed case.
>>>
>>> Mark
>>>
>>>
>>> On Thursday, September 22, 2016, Richard Feldman <
>>> richard.t.feld...@gmail.com> wrote:
>>>
 I'm not sure what you mean there - what part about the status quo
 regarding form elements doesn't seem sensible?

 On Thu, Sep 22, 2016, 8:43 PM Max Goldstein 
 wrote:

> I really like Mark's summary, and I think Richard is incorrect to
> dismiss the first point:
>
> 1. Make sure the virtual DOM works "sensibly" with elements with
> hidden local state.
>
> Checkboxes, drop downs, and other form inputs are a root problem.
> Maybe the solution is web components, but maybe not.
>
> --
> 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 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.

Re: [elm-discuss] Elm, Objects and Components

[Mark Hamburg]

Keyed expects all of the siblings to be keyed. This means that if you use
one stateful (and since part of the point is that this is opaque, so you
should probably assume stateful) web component in a list of siblings, you
need to use keys keys on all of them.

What's more that statefulness propagates up the tree. If you need to be
protected from accidentally re-creating views at one level, you need that
protection all the way up to the root.

Each of these issues gets mitigated if the sequence of child views is fixed
but without attention to the issue it's a lurking source of spurious bugs
that the type system won't catch for you and that will instead require
intensive testing to protect against.

Mark

On Thursday, September 22, 2016, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> I'm confused - Keyed is explicitly the solution to this...what is
> insufficient about Keyed as a solution?
>
> On Thu, Sep 22, 2016 at 9:11 PM Mark Hamburg  > wrote:
>
>> The issue is that when you have external state, there need to be ways —
>> features, patterns of coding, etc — that prevent accidental destruction of
>> one component accompanied by creation of a new component when what one
>> wanted was an update to the existing component. This depends on having a
>> notion of identity that the HTML support in Elm eschews except for the
>> keyed case.
>>
>> Mark
>>
>>
>> On Thursday, September 22, 2016, Richard Feldman <
>> richard.t.feld...@gmail.com
>> > wrote:
>>
>>> I'm not sure what you mean there - what part about the status quo
>>> regarding form elements doesn't seem sensible?
>>>
>>> On Thu, Sep 22, 2016, 8:43 PM Max Goldstein 
>>> wrote:
>>>
 I really like Mark's summary, and I think Richard is incorrect to
 dismiss the first point:

 1. Make sure the virtual DOM works "sensibly" with elements with hidden
 local state.

 Checkboxes, drop downs, and other form inputs are a root problem. Maybe
 the solution is web components, but maybe not.

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

Re: [elm-discuss] Elm, Objects and Components

[Mark Hamburg]

The issue is that when you have external state, there need to be ways —
features, patterns of coding, etc — that prevent accidental destruction of
one component accompanied by creation of a new component when what one
wanted was an update to the existing component. This depends on having a
notion of identity that the HTML support in Elm eschews except for the
keyed case.

Mark

On Thursday, September 22, 2016, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> I'm not sure what you mean there - what part about the status quo
> regarding form elements doesn't seem sensible?
>
> On Thu, Sep 22, 2016, 8:43 PM Max Goldstein  > wrote:
>
>> I really like Mark's summary, and I think Richard is incorrect to dismiss
>> the first point:
>>
>> 1. Make sure the virtual DOM works "sensibly" with elements with hidden
>> local state.
>>
>> Checkboxes, drop downs, and other form inputs are a root problem. Maybe
>> the solution is web components, but maybe not.
>>
>> --
>> 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.

Re: [elm-discuss] Elm, Objects and Components

[Richard Feldman]

I'm not sure what you mean there - what part about the status quo regarding
form elements doesn't seem sensible?

On Thu, Sep 22, 2016, 8:43 PM Max Goldstein  wrote:

> I really like Mark's summary, and I think Richard is incorrect to dismiss
> the first point:
>
> 1. Make sure the virtual DOM works "sensibly" with elements with hidden
> local state.
>
> Checkboxes, drop downs, and other form inputs are a root problem. Maybe
> the solution is web components, but maybe not.
>
> --
> 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.

Re: [elm-discuss] Elm, Objects and Components

[Max Goldstein]

I really like Mark's summary, and I think Richard is incorrect to dismiss the 
first point:

1. Make sure the virtual DOM works "sensibly" with elements with hidden local 
state. 

Checkboxes, drop downs, and other form inputs are a root problem. Maybe the 
solution is web components, but maybe not. 

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

Re: [elm-discuss] Elm, Objects and Components

[OvermindDL1]

Yes, then you pay the price twice.  That would be hard to solve
because an elm module != js module, which would solve the problem, but
would require an overhaul in how elm generates code and would
basically just be doing what bucklescript does then as a language
(though without TEA).


On Thu, Sep 22, 2016 at 9:41 AM, Ambrose Kofi Laing  wrote:
> I'm guessing the question from two posts ago was: if someone creates a
> component from a .elm file, and gives you their .js (but not their .elm),
> and you also create your own .elm file and use both together, do you pay the
> price of having the standard library twice in your code?
>
>
> On Thu, Sep 22, 2016 at 11:34 AM, OvermindDL1  wrote:
>>
>> On Thursday, September 22, 2016 at 9:17:47 AM UTC-6, Rupert Smith wrote:
>>>
>>> On Thursday, September 22, 2016 at 3:12:27 PM UTC+1, OvermindDL1 wrote:

 You can compile multiple main files together and they will share a
 code-base, standard library, and all such.
>>>
>>>
>>> I had not considered that - useful if you want to take a one page, one
>>> main approach rather than nested TEA with a router in a single main.
>>>
>>> Still, you'd have to compile the components all together at the same time
>>> would you not? If I used some components from one auther and some from
>>> another, the code sharing would be lost.
>>
>>
>> Only if they did not pull from the same root library.  With elm make you
>> can specify multiple main files and all main files and everything they use
>> will be included and all merged into one big javascript.  If you have two
>> main files, say MyMain.elm and AnotherMain.elm, then in javascript you can
>> instance them via Elm.MyMain.embed(..) and Elm.AnotherMain.embed(..).  It is
>> just like compiling a single app, but you just include multiple main files
>> (which may indeed be just a simple do-near-nothing main that just calls the
>> main of a library).
>>
>> --
>> 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.

Re: [elm-discuss] Elm, Objects and Components

[OvermindDL1]

On Thursday, September 22, 2016 at 9:17:47 AM UTC-6, Rupert Smith wrote:
>
> On Thursday, September 22, 2016 at 3:12:27 PM UTC+1, OvermindDL1 wrote:
>>
>> You can compile multiple main files together and they will share a 
>> code-base, standard library, and all such.
>>
>
> I had not considered that - useful if you want to take a one page, one 
> main approach rather than nested TEA with a router in a single main.
>
> Still, you'd have to compile the components all together at the same time 
> would you not? If I used some components from one auther and some from 
> another, the code sharing would be lost.
>

Only if they did not pull from the same root library.  With elm make you 
can specify multiple main files and all main files and everything they use 
will be included and all merged into one big javascript.  If you have two 
main files, say MyMain.elm and AnotherMain.elm, then in javascript you can 
instance them via Elm.MyMain.embed(..) and Elm.AnotherMain.embed(..).  It 
is just like compiling a single app, but you just include multiple main 
files (which may indeed be just a simple do-near-nothing main that just 
calls the main of a library). 

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

Re: [elm-discuss] Elm, Objects and Components

['Rupert Smith' via Elm Discuss]

On Thursday, September 22, 2016 at 3:12:27 PM UTC+1, OvermindDL1 wrote:
>
> You can compile multiple main files together and they will share a 
> code-base, standard library, and all such.
>

I had not considered that - useful if you want to take a one page, one main 
approach rather than nested TEA with a router in a single main.

Still, you'd have to compile the components all together at the same time 
would you not? If I used some components from one auther and some from 
another, the code sharing would be lost.

 

>
> On Thursday, September 22, 2016 at 8:01:58 AM UTC-6, Rupert Smith wrote:
>>
>> On Wednesday, September 21, 2016 at 10:59:00 PM UTC+1, John Mayer wrote:
>>>
>>> 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.
>>>
>>
>> The output .js from Elm is quite big, even once minified. Does that mean 
>> that every web component written in Elm will have 100K+ of javascript 
>> embedded inside it? Its a great idea, but perhaps there needs to be a way 
>> to share the code that is common. 
>>
>

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

Re: [elm-discuss] Elm, Objects and Components

[OvermindDL1]

You can compile multiple main files together and they will share a 
code-base, standard library, and all such.

On Thursday, September 22, 2016 at 8:01:58 AM UTC-6, Rupert Smith wrote:
>
> On Wednesday, September 21, 2016 at 10:59:00 PM UTC+1, John Mayer wrote:
>>
>> 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.
>>
>
> The output .js from Elm is quite big, even once minified. Does that mean 
> that every web component written in Elm will have 100K+ of javascript 
> embedded inside it? Its a great idea, but perhaps there needs to be a way 
> to share the code that is common. 
>

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

Re: [elm-discuss] Elm, Objects and Components

['Rupert Smith' via Elm Discuss]

On Wednesday, September 21, 2016 at 10:59:00 PM UTC+1, John Mayer wrote:
>
> 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.
>

The output .js from Elm is quite big, even once minified. Does that mean 
that every web component written in Elm will have 100K+ of javascript 
embedded inside it? Its a great idea, but perhaps there needs to be a way 
to share the code that is common. 

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

Re: [elm-discuss] Elm, Objects and Components

[John Mayer]

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"  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  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
>> 
>> 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 

Re: [elm-discuss] Elm, Objects and Components

[Mark Hamburg]

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  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
> 
> 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  to your index.html
>>>3. Add this before the script that imports your elm.js: 
>>>// register an element
>>>MyElement = Polymer({is: 'my-element',
>>>created: function() { this.textContent = 'My element!'; }
>>>});
>>>
>>>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 

Re: [elm-discuss] Elm, Objects and Components

[Richard Feldman]

No problem! Hope it works well. :)

On Tue, Sep 20, 2016 at 2:22 PM Peter Damoc  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
 
 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  to
>>your index.html
>>3. Add this before the script that imports your elm.js: 
>>// register an element
>>MyElement = Polymer({is: 'my-element',
>>created: function() { this.textContent = 'My element!'; }
>>});
>>
>>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.

Re: [elm-discuss] Elm, Objects and Components

[Peter Damoc]

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
>>> 
>>> 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  to
>your index.html
>3. Add this before the script that imports your elm.js: 
>// register an element
>MyElement = Polymer({is: 'my-element',
>created: function() { this.textContent = 'My element!'; }
>});
>
>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 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.

Re: [elm-discuss] Elm, Objects and Components

[Richard Feldman]

Yeah, I think this is a great thing for people to be playing around with. :)

Underexplored territory!

On Tue, Sep 20, 2016, 2:16 PM James Wilson  wrote:

> I haze thought about using web components like this too. You could even go
> a step further and have web components that embed Elm inside themselves the
> same way you can whack Elm into any other element. So perhaps a collection
> of Elmish web components points one path forward!
>
> The other nice thing about embedding web components into Elm as easily as
> we can is that they can be used to wrap native JS things into El as well.
> For example one might make a web component to render a google map based on
> ita attributes, and in Elm we just Html.node "google-map" [] []. Definitely
> something I need to play with more!
>
> --
> 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.

Re: [elm-discuss] Elm, Objects and Components

[James Wilson]

I haze thought about using web components like this too. You could even go a 
step further and have web components that embed Elm inside themselves the same 
way you can whack Elm into any other element. So perhaps a collection of Elmish 
web components points one path forward! 

The other nice thing about embedding web components into Elm as easily as we 
can is that they can be used to wrap native JS things into El as well. For 
example one might make a web component to render a google map based on ita 
attributes, and in Elm we just Html.node "google-map" [] []. Definitely 
something I need to play with more!

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

Re: [elm-discuss] Elm, Objects and Components

[Nick H]

>
> So the question is -- if you treat a TEA program as just a piece of data,
> a four-piece record which does nothing (until you run it with
> Html.program), can you define any standard operations which can take two
> TEA programs and be guaranteed to give you another TEA program?  If there
> were such an operation that operation would be closed.  In the mathematical
> sense.  I think what Peter D. was arguing for.
>

I see. And this kind of thing is only possible if the functions for
analyzing input and producing output are bound with the program state.



On Tue, Sep 20, 2016 at 4:36 AM, Ambrose Laing  wrote:

> I also understood "closure" as used by Abelson to mean closure in the
> mathematical sense.  The notion that if you apply a binary operation to two
> items of one type, you get another item of the same type.  I do see it as
> being strongly related to the question of components or private state.
>
> In elm, we already have examples of closure in being able to combine
> functions to obtain a larger function, combine records to obtain a larger
> record, many Cmd msg to obtain another Cmd msg (using Cmd.batch), etc.
> Abelson's example was one of combining two pieces of a rectangle type, to
> obtain a larger rectangle.
>
> Right now consider what a TEA program is.  One could argue that a TEA
> program is in some sense a piece of data (it is a record with four standard
> components called model, update, view and subscriptions, which must have
> certain types).  If you think of a TEA program this way, it is a piece of
> data that does nothing (analogous to a binary executable).  However if you
> run the TEA program with Html.program or Html.programWithFlags, then it
> becomes an interactive thing, that can pretend to a naive end-user that it
> is stateful (analogous to a process).  We could nit-pick and refine our
> statement to further clarify that it is not in fact stateful in the sense
> of being mutable, but rather uses immutability and that all the true
> statefulness is managed for you by the elm framework.
>
> So the question is -- if you treat a TEA program as just a piece of data,
> a four-piece record which does nothing (until you run it with
> Html.program), can you define any standard operations which can take two
> TEA programs and be guaranteed to give you another TEA program?  If there
> were such an operation that operation would be closed.  In the mathematical
> sense.  I think what Peter D. was arguing for.
>
>
>
> On Tuesday, September 20, 2016 at 1:49:15 AM UTC-4, Nick H wrote:
>>
>> In the lecture Peter links to, the word "closure" is just being used to
>> mean a function `a -> a`, where the return type matches the argument type.
>> Like the mathematical sense of "the integers are closed with respect to
>> addition."
>>
>> Its a useful property for a function to have, but in the sense used here,
>> it's not really related to the question of components or private state.
>>
>> On Mon, Sep 19, 2016 at 10:34 PM, Max Goldstein 
>> wrote:
>>
>>> Closure sounds like a nice property in theory. In practice, it's built
>>> on the idea that you have to hide things, because things tend to break and
>>> encapsulation is the only way to keep that breakage from spiraling out of
>>> control. But in Elm, things don't break very often, and when they do the
>>> compiler is there to catch them. So don't worry about components, just use
>>> functions.
>>>
>>> That said, there's a very important point in OP about state for HTML
>>> tags. For example, the reuse section of the guide  has an example with
>>> checkboxes. These boxes send messages to toggle their state when they are
>>> clicked. But, there is no way to pre-populate the state of the checkboxes
>>> for example with information you get from the server. In another thread, I
>>> think this is worth discussing. If some HTML components are state full what
>>> do we do about that, without jumping down the rabbit hole of components?
>>>
>>> --
>>> 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...@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.

Re: [elm-discuss] Elm, Objects and Components

[Brian Marick]

> On Sep 20, 2016, at 3:21 AM, Richard Feldman  
> wrote:
> 
> 
> If nothing is wrong with Web Components, why not use them?
> 
> There are a ton of them 
>  you 
> could use right now, for MDL in particular, that work right off the shelf.
> 
> Why block on a hypothetical future language feature when there already exists 
> a way for you to code your Elm application the way you would if that feature 
> existed?

Is there any sample code I can look at to see how to do this? (Note: very much 
a front-end newbie - tell me if using them would be too much of a leap.)

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

Re: [elm-discuss] Elm, Objects and Components

[Peter Damoc]

On Tue, Sep 20, 2016 at 2:36 PM, Ambrose Laing  wrote:

> So the question is -- if you treat a TEA program as just a piece of data,
> a four-piece record which does nothing (until you run it with
> Html.program), can you define any standard operations which can take two
> TEA programs and be guaranteed to give you another TEA program?  If there
> were such an operation that operation would be closed.  In the mathematical
> sense.  I think what Peter D. was arguing for.
>

Yes, that is the point.

Right now, main accepts Html, if the output of `Platform.program` would be
`Html`, then this would constitute a component that could be mixed with
other components and could also be used as the value for `main`.

programWithFlags could become just a regular function that would mimic the
API of a regular component (config -> Html msg)
programWithFlags : Flags -> Html msg

Maybe Html would not be the best name, maybe UI would be better. The idea
being that one would have a way to talk about this things just as
pleasantly as they can talk about html components.


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

Re: [elm-discuss] Elm, Objects and Components

[John Mayer]

Here are my questions

How do you define a web component in Elm. What's the boilerplate? Can it be
auto-generated from any Elm app? (my gut here says that ports become
similar to on-change events)

How do you consume web components with Elm's virtual-dom. Are there issues?
There used to be concerns surrounding the virtual DOM and the shadow DOM
interaction.

Ignoring non-Elm boilerplate, is the code better? Does it solve our
concerns about components?

How's performance compared to using the top-level dispatcher (particularly
at scale - e.g. hundreds of datepickers)

If all of the above are favorable, then we can start thinking about adding
a feature to Elm.

I think we learn a lot by running this experiment.

On Sep 20, 2016 6:15 AM, "John Mayer"  wrote:

> You shouldn't need Polymer. Just web components, which are a standard and
> implemented in most browsers (probably all browsers on which Elm runs).
>
> It will be a few dozen lines of JS and HTML, and there might be quirks. If
> it works, it still won't be super elegant, but it could build the case for
> adopting the standard as part of Elm if these experiments go well.
>
> On Sep 20, 2016 5:00 AM, "Peter Damoc"  wrote:
>
>> On Tue, Sep 20, 2016 at 11:21 AM, 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
>>> 
>>> 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. :)
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>> --
>> 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.

Re: [elm-discuss] Elm, Objects and Components

[John Mayer]

You shouldn't need Polymer. Just web components, which are a standard and
implemented in most browsers (probably all browsers on which Elm runs).

It will be a few dozen lines of JS and HTML, and there might be quirks. If
it works, it still won't be super elegant, but it could build the case for
adopting the standard as part of Elm if these experiments go well.

On Sep 20, 2016 5:00 AM, "Peter Damoc"  wrote:

> On Tue, Sep 20, 2016 at 11:21 AM, 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
>>  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. :)
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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.

Re: [elm-discuss] Elm, Objects and Components

[Peter Damoc]

On Tue, Sep 20, 2016 at 11:21 AM, 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
>  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. :)


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

Re: [elm-discuss] Elm, Objects and Components

[John Orford]

(I found MDL web components to be pretty hit and miss when used with Elm -
perhaps that's changed since 0.16 - would love to hear more on this topic)


On Tue, 20 Sep 2016 at 10:21 Richard Feldman 
wrote:

>  Or you can define a Web Component
>>>  like
>>>  and then call node "myRadioButton" to create one. No
>>> C++ involved.
>>>
>>> What's wrong with that?
>>>
>>> Nothing.
>> If Elm provides an official way to use TEA in order to implement Custom
>> Elements the discussions around Components will go away.
>> If someone comes and says "What if I have many small components that are
>> unavoidably stateful" the answer would be, "just use
>> elm-lang/custom-element"
>>
>
> If nothing is wrong with Web Components, why not use them?
>
> There are a ton of them
>  you
> could use right now, for MDL in particular, that work right off the shelf.
>
> Why block on a hypothetical future language feature when there already
> exists a way for you to code your Elm application the way you would if that
> feature existed?
>
>> --
> 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.

Re: [elm-discuss] Elm, Objects and Components

[Peter Damoc]

On Tue, Sep 20, 2016 at 4:29 AM, Ian Mackenzie 
wrote:

> Peter, you may be interested in (and I'd appreciate your feedback on) a
> little library I've been working on for composable input widgets:
> https://github.com/kintail/input-widget
>

I took a superficial look at the library and it looks very interesting.
I need to play with it a little bit in order to give a proper feedback but
I wanted to say that this looks similar to an idea I had (around
serializing internal messages and internal state) only that it looks much
much better.
I'll get back with more feedback.


On Tue, Sep 20, 2016 at 5:39 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> If these components are implemented in C++ and wrapped by the virtual-dom,
>>> we are lucky, we can use them. If they are not, we are out of luck.
>>>
>>
>  Or you can define a Web Component
>  like
>  and then call node "myRadioButton" to create one. No C++
> involved.
>
> What's wrong with that?
>
> Nothing.
If Elm provides an official way to use TEA in order to implement Custom
Elements the discussions around Components will go away.
If someone comes and says "What if I have many small components that are
unavoidably stateful" the answer would be, "just use
elm-lang/custom-element"

I would also like to add that actual Custom Elements aren't even truly
needed here.
If an hypothetical elm-lang/custom-element library would create just
regular virtual-dom elements the issue would still be solved.


On Tue, Sep 20, 2016 at 5:47 AM, Nick H  wrote:

> Peter, I also think the pain that you are feeling has a lot to do with the
> fact that there simply aren't very many UI libraries for Elm. Elm-mdl is
> the only one I ever hear anybody talk about. You are asking for an
> officially-sanctioned alternative to elm-mdl, but why does there need to be
> one?
>

Just to clarify a little bit, I was asking for an officially sanctioned
alternative to the approach elm-mdl took, not of the actual library.

The need for something like this stems from the fact that if we want to
promote elm to be an alternative to current front-end technologies, you
have to cater to beginners. They too should be able to create great
webpages.
The only way a beginner can create something nice looking and modern is to
rest on the work done by others. To use "components" that others have
implemented and optimized.

For example, I can take something like
http://www.creative-tim.com/live/paper-kit-pro
and with very little knowledge produce something that looks nice.

This would be close to impossible for a beginner with minimal CSS knowledge
working directly with elm-html and some external CSS tool or maybe elm-css.

There is also the "constrains liberate" idea. If the beginner has a great
library, they can stay within that library and be free from the hustle of
choosing which UI library to choose.
For example, if elm-html library would be supplemented by an elm-ui library
that is just as easy to use as elm-html but it is as extensive as Semantic
UI and just as customizable (themes) the discussion around small stateful
components might just go away.
elm-mdl might get reimplemented as just another theme of that elm-ui OR
they might use elm-ui as an example and do a similar implementation
(assuming that elm-ui does not rest itself on some Native code).





-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

Re: [elm-discuss] Elm, Objects and Components

[Nick H]

In the lecture Peter links to, the word "closure" is just being used to
mean a function `a -> a`, where the return type matches the argument type.
Like the mathematical sense of "the integers are closed with respect to
addition."

Its a useful property for a function to have, but in the sense used here,
it's not really related to the question of components or private state.

On Mon, Sep 19, 2016 at 10:34 PM, Max Goldstein 
wrote:

> Closure sounds like a nice property in theory. In practice, it's built on
> the idea that you have to hide things, because things tend to break and
> encapsulation is the only way to keep that breakage from spiraling out of
> control. But in Elm, things don't break very often, and when they do the
> compiler is there to catch them. So don't worry about components, just use
> functions.
>
> That said, there's a very important point in OP about state for HTML tags.
> For example, the reuse section of the guide  has an example with
> checkboxes. These boxes send messages to toggle their state when they are
> clicked. But, there is no way to pre-populate the state of the checkboxes
> for example with information you get from the server. In another thread, I
> think this is worth discussing. If some HTML components are state full what
> do we do about that, without jumping down the rabbit hole of components?
>
> --
> 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.

Re: [elm-discuss] Elm, Objects and Components

[Max Goldstein]

Closure sounds like a nice property in theory. In practice, it's built on the 
idea that you have to hide things, because things tend to break and 
encapsulation is the only way to keep that breakage from spiraling out of 
control. But in Elm, things don't break very often, and when they do the 
compiler is there to catch them. So don't worry about components, just use 
functions. 

That said, there's a very important point in OP about state for HTML tags. For 
example, the reuse section of the guide  has an example with checkboxes. These 
boxes send messages to toggle their state when they are clicked. But, there is 
no way to pre-populate the state of the checkboxes for example with information 
you get from the server. In another thread, I think this is worth discussing. 
If some HTML components are state full what do we do about that, without 
jumping down the rabbit hole of components?

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

Re: [elm-discuss] Elm, Objects and Components

[Nick H]

Peter, I also think the pain that you are feeling has a lot to do with the
fact that there simply aren't very many UI libraries for Elm. Elm-mdl is
the only one I ever hear anybody talk about. You are asking for an
officially-sanctioned alternative to elm-mdl, but why does there need to be
one?

I think the core libraries -- html, svg, vdom -- are doing the job that's
required of them. They provide a low-level interface to the underlying web
technology. Think this is a much better choice for the platform than if
Evan were pushing a high-level, design-opinionated UI library (elm-graphics
or elm-mdl), because it gives Elm users much more freedom to build and
choose the tools that fit their needs best.

It sucks for early adopters like us, especially if we were hoping to get
away from CSS & HTML completely. We have to be happy working with the
available tools, or patient enough to wait for a library to be written, or
crazy enough to write a library ourselves. Those are really the only
options.


On Mon, Sep 19, 2016 at 5:13 PM, Nick H  wrote:

> The  way I view it, the core idea behind Components is the closure
>> property that professor Abelson speaks about here:
>> https://youtu.be/2QgZVYI3tDs?t=2194
>>
>> Building complexity by combining things and getting the same kind of
>> thing that can then be used to combine with other things.
>
>
> Abelson is just defining and combining functions. Adjusting for syntax,
> you could write code in Elm that looks essentially the same.
>
> (DEFINE P (BESIDE G (ROT-180 (FLIP G)) .5))
>
> What is conspicuously absent in this example is anything that looks like
> an object or a component. All of the old state is in "G". All of the
> behavior is in the functions. All of the new state is in "P".
>
> Abelson did not show in his slides here the code for rendering the view.
> But this would just be a function that takes P (or G) as input. In Elm, it
> would just return Html.
>
> This has nothing to do with the business objectives of that UI. It is just
>> a piece of transitory, accidental information.
>>
>
> As far as the view function is concerned, there is no difference. Every
> bit of information needed to draw the view needs to get passed to the view
> function as an argument.
>
> That doesn't mean that all of your update functions need to operate on the
> totality of your state (although in Abelson's example, they do!). You
> should have separate functions to deal with updating that UI state and
> aspects of your "business" state, and these can be delegated from your
> overarching update function.
>
> Scheme is a nice illustration that functions are the only tool you need to
> manage complexity. If there are pain points in scaling Elm programs, the
> lack of components aren't the culprit.
>
>
>
>
> On Mon, Sep 19, 2016 at 2:57 PM, Peter Damoc  wrote:
>
>> Evan points out that people would consider thinking in terms of Objects
>> for certain parts of the UI as a bad idea
>> https://youtu.be/LCNs92YQjhw?t=1340
>>
>> he also points that Components are more or less the same thing and that
>> we should move away from thinking about them.
>>
>> The  way I view it, the core idea behind Components is the closure
>> property that professor Abelson speaks about here:
>> https://youtu.be/2QgZVYI3tDs?t=2194
>>
>> Building complexity by combining things and getting the same kind of
>> thing that can then be used to combine with other things.
>>
>> The sidebar would be a *thing, a widget, an object, a component. * Now I
>> could implement it right now by using the components of elm-html and have
>> that component be a simple function where some elm-html widgets are
>> combined in a certain way.
>>
>> The problem is that *some of the components* that are needed in a modern
>> UI need small state. If these components are implemented in C++ and wrapped
>> by the virtual-dom, we are lucky, we can use them. If they are not, we are
>> out of luck. Even a humble dropdown cannot be used as pleasantly as a
>> radiobox because it needs a small "isVisible" piece of state. This has
>> nothing to do with the business objectives of that UI. It is just a piece
>> of transitory, accidental information. The same with an accordion, a
>> datepicker or a slider. These cannot be used as pleasantly as regular
>> elm-html components.
>>
>> elm-mdl has that closure property. One could create components that
>> combine and behave like elm-mdl components.
>>
>> And there is no official, blessed alternative that would have this
>> property for components that need a little bit of state.
>>
>> When I first saw the Elm Architecture I thought that it will evolve into
>> something like a component architecture. In my naivety I thought that we
>> will get some kind of function that would take a model, update and the view
>> and would output some kind of component that would be usable in place of
>> any other elm-html component. And the state would be sanely managed by the

Re: [elm-discuss] Elm, Objects and Components

[Richard Feldman]

>
> If these components are implemented in C++ and wrapped by the virtual-dom, 
>> we are lucky, we can use them. If they are not, we are out of luck.
>>
>
 Or you can define a Web Component 
 like 
 and then call node "myRadioButton" to create one. No C++ 
involved.

What's wrong with that?

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

Re: [elm-discuss] Elm, Objects and Components

[Ian Mackenzie]

Peter, you may be interested in (and I'd appreciate your feedback on) a 
little library I've been working on for composable input widgets: 
https://github.com/kintail/input-widget

It seemed to me that in many cases of 'little bits of local state', the 
widget in question is an input widget of some sort like a fancy dropdown, a 
date picker, a small form with a few fields + validation etc. where it has 
some transient internal state to keep track of but all the higher-level 
code really cares about is the output value produced. As a result I created 
the input-widget package to experiment with combinators (map, map2 etc.) 
for input widgets and I think so far it's worked out pretty well; you can 
pretty easily do things like add validation or decoration to widgets, 
combine a 'first name' and a 'last name' widget to produce a 'person' 
widget, etc. You can also define custom input widgets using TEA functions 
(which can then be composed etc. just like any other input widget) or 
easily embed input widgets into a normal TEA program. Right now the only 
primitive widgets I've implemented are 'checkbox' and 'lineEdit', and 
there's no documentation yet, but you should be able to check out the 
examples directory to see how things work.

Internally this does a couple dirty-ish things (the 'State' type includes a 
bunch of functions which is generally frowned upon, and messages are all 
passed around as JSON to avoid an explosion of types) but from the outside 
it should be quite type safe (I'd love to hear about any holes people find).

Ultimately I'd like to create a parallel output-widget package for 
composable output widgets following the sortable-table example (internal 
state handled internally, current value to display passed into 'view').

On Tuesday, 20 September 2016 10:13:43 UTC+10, Nick H wrote:
>
> The  way I view it, the core idea behind Components is the closure 
>> property that professor Abelson speaks about here:
>> https://youtu.be/2QgZVYI3tDs?t=2194
>>
>> Building complexity by combining things and getting the same kind of 
>> thing that can then be used to combine with other things.
>
>
> Abelson is just defining and combining functions. Adjusting for syntax, 
> you could write code in Elm that looks essentially the same.
>
> (DEFINE P (BESIDE G (ROT-180 (FLIP G)) .5))
>
> What is conspicuously absent in this example is anything that looks like 
> an object or a component. All of the old state is in "G". All of the 
> behavior is in the functions. All of the new state is in "P".
>
> Abelson did not show in his slides here the code for rendering the view. 
> But this would just be a function that takes P (or G) as input. In Elm, it 
> would just return Html.
>
> This has nothing to do with the business objectives of that UI. It is just 
>> a piece of transitory, accidental information.
>>
>
> As far as the view function is concerned, there is no difference. Every 
> bit of information needed to draw the view needs to get passed to the view 
> function as an argument.
>
> That doesn't mean that all of your update functions need to operate on the 
> totality of your state (although in Abelson's example, they do!). You 
> should have separate functions to deal with updating that UI state and 
> aspects of your "business" state, and these can be delegated from your 
> overarching update function.
>
> Scheme is a nice illustration that functions are the only tool you need to 
> manage complexity. If there are pain points in scaling Elm programs, the 
> lack of components aren't the culprit.
>
>
>  
>
> On Mon, Sep 19, 2016 at 2:57 PM, Peter Damoc  > wrote:
>
>> Evan points out that people would consider thinking in terms of Objects 
>> for certain parts of the UI as a bad idea
>> https://youtu.be/LCNs92YQjhw?t=1340
>>
>> he also points that Components are more or less the same thing and that 
>> we should move away from thinking about them. 
>>
>> The  way I view it, the core idea behind Components is the closure 
>> property that professor Abelson speaks about here:
>> https://youtu.be/2QgZVYI3tDs?t=2194
>>
>> Building complexity by combining things and getting the same kind of 
>> thing that can then be used to combine with other things. 
>>
>> The sidebar would be a *thing, a widget, an object, a component. * Now I 
>> could implement it right now by using the components of elm-html and have 
>> that component be a simple function where some elm-html widgets are 
>> combined in a certain way. 
>>
>> The problem is that *some of the components* that are needed in a modern 
>> UI need small state. If these components are implemented in C++ and wrapped 
>> by the virtual-dom, we are lucky, we can use them. If they are not, we are 
>> out of luck. Even a humble dropdown cannot be used as pleasantly as a 
>> radiobox because it needs a small "isVisible" piece of state. This has 
>> nothing to do with the business objectives of that UI. It is just a piece 
>> of transitory, 

Re: [elm-discuss] Elm, Objects and Components

[Nick H]

>
> The  way I view it, the core idea behind Components is the closure
> property that professor Abelson speaks about here:
> https://youtu.be/2QgZVYI3tDs?t=2194
>
> Building complexity by combining things and getting the same kind of thing
> that can then be used to combine with other things.


Abelson is just defining and combining functions. Adjusting for syntax, you
could write code in Elm that looks essentially the same.

(DEFINE P (BESIDE G (ROT-180 (FLIP G)) .5))

What is conspicuously absent in this example is anything that looks like an
object or a component. All of the old state is in "G". All of the behavior
is in the functions. All of the new state is in "P".

Abelson did not show in his slides here the code for rendering the view.
But this would just be a function that takes P (or G) as input. In Elm, it
would just return Html.

This has nothing to do with the business objectives of that UI. It is just
> a piece of transitory, accidental information.
>

As far as the view function is concerned, there is no difference. Every bit
of information needed to draw the view needs to get passed to the view
function as an argument.

That doesn't mean that all of your update functions need to operate on the
totality of your state (although in Abelson's example, they do!). You
should have separate functions to deal with updating that UI state and
aspects of your "business" state, and these can be delegated from your
overarching update function.

Scheme is a nice illustration that functions are the only tool you need to
manage complexity. If there are pain points in scaling Elm programs, the
lack of components aren't the culprit.




On Mon, Sep 19, 2016 at 2:57 PM, Peter Damoc  wrote:

> Evan points out that people would consider thinking in terms of Objects
> for certain parts of the UI as a bad idea
> https://youtu.be/LCNs92YQjhw?t=1340
>
> he also points that Components are more or less the same thing and that we
> should move away from thinking about them.
>
> The  way I view it, the core idea behind Components is the closure
> property that professor Abelson speaks about here:
> https://youtu.be/2QgZVYI3tDs?t=2194
>
> Building complexity by combining things and getting the same kind of thing
> that can then be used to combine with other things.
>
> The sidebar would be a *thing, a widget, an object, a component. * Now I
> could implement it right now by using the components of elm-html and have
> that component be a simple function where some elm-html widgets are
> combined in a certain way.
>
> The problem is that *some of the components* that are needed in a modern
> UI need small state. If these components are implemented in C++ and wrapped
> by the virtual-dom, we are lucky, we can use them. If they are not, we are
> out of luck. Even a humble dropdown cannot be used as pleasantly as a
> radiobox because it needs a small "isVisible" piece of state. This has
> nothing to do with the business objectives of that UI. It is just a piece
> of transitory, accidental information. The same with an accordion, a
> datepicker or a slider. These cannot be used as pleasantly as regular
> elm-html components.
>
> elm-mdl has that closure property. One could create components that
> combine and behave like elm-mdl components.
>
> And there is no official, blessed alternative that would have this
> property for components that need a little bit of state.
>
> When I first saw the Elm Architecture I thought that it will evolve into
> something like a component architecture. In my naivety I thought that we
> will get some kind of function that would take a model, update and the view
> and would output some kind of component that would be usable in place of
> any other elm-html component. And the state would be sanely managed by the
> runtime with messages and all will be well.
>
> The elm-parts part of elm-mdl kinda does what I imagine that Elm
> Architecture would evolve into. I'm not referring to the implementation
> details of elm-parts. I'm referring to the stuff like this line:
> https://github.com/debois/elm-mdl/blob/master/src/Material/Button.elm#L417
> a call that would just wire things together and give me the thing that is
> the same as the rest of the things.
>
> I think that solving the need that prompted elm-parts would basically mean
> solving the Components issue.
>
> What am I missing here? I understand that this is a complex issue but why
> is this particular *need of a nice way of combining things that have
> behavior* not being addressed?
>
> I'm seeing the word *state* thrown around a lot but seriously, has state
> been shown to be an issue in an Elm program? (I'm talking real issues with
> a SSCCE attached not hypothetical stuff). I understand how this can be a
> problem in a language with imperative execution and global state but even
> in those languages if care is taken for state to be localized, things are
> manageable.
>
> Why not have some kind of automatic state 

Re: [elm-discuss] Elm, Objects and Components

[Dylan Sale]

"Building complexity by combining things and getting the same kind of thing
that can then be used to combine with other things. "

This only works if you have an abstraction that you can't "look into". It's
actually not the case for most UI libraries that they are composable in
this way. Generally the "view" class is useless in itself and you have to
down cast to actually do anything (to a label to change the text for
example).

This is relevant to storing state because if views were a monoid (ie,
composable without abstraction leaks) then the state would be invisible to
the business logic and so could be managed internally and no one would
care. The issue is that sometimes, the business logic might care about that
state, maybe for serialisation and session save/restore.

One solution is to make the views mutable and downcast everywhere. The
other is to maintain the abstraction and so make the views immutable and
keep the state somewhere else. It's just a trade-off. I don't think you
should need to see exact examples of times it has been a problem to
understand that it will always become a problem if you add state
indiscriminately.

Theorem: The more independent stores of state you have, the faster the
difference between representable state and valid state increases.

Say you have 2 views with internal state stores A, B that have two 8 bit
integers as state. You now have 2^16 representable states (all combinations
of A and B). Maybe you know that B will only be used if A is 0, so in your
business logic you only use 2^9 states, that's 2^7 states that are
representable but invalid. (The math may be off, but I hope you get the
point.)

Now you add another view with more state C. This one is only used if both A
and B are 0. The difference between representable state and valid state may
increase exponentially, causing more chance that your total state will slip
into the invalid space due to a bug that the compiler can't help with.

So the argument that you should only have a single source of state where
all representable states are valid, and the views should be a total
function of that state seems to be the better from a risk minimisation
point of view, and really the only answer if your goal is bug free code.

I think it's still an open question as to how to do this in a performant
way and have the flexibility of a component/object model but Evan et al
seem to be making great strides.

Sorry if I went off topic. Typed this on the bus.

On Tue, 20 Sep 2016, 07:27 Peter Damoc,  wrote:

> Evan points out that people would consider thinking in terms of Objects
> for certain parts of the UI as a bad idea
> https://youtu.be/LCNs92YQjhw?t=1340
>
> he also points that Components are more or less the same thing and that we
> should move away from thinking about them.
>
> The  way I view it, the core idea behind Components is the closure
> property that professor Abelson speaks about here:
> https://youtu.be/2QgZVYI3tDs?t=2194
>
> Building complexity by combining things and getting the same kind of thing
> that can then be used to combine with other things.
>
> The sidebar would be a *thing, a widget, an object, a component. * Now I
> could implement it right now by using the components of elm-html and have
> that component be a simple function where some elm-html widgets are
> combined in a certain way.
>
> The problem is that *some of the components* that are needed in a modern
> UI need small state. If these components are implemented in C++ and wrapped
> by the virtual-dom, we are lucky, we can use them. If they are not, we are
> out of luck. Even a humble dropdown cannot be used as pleasantly as a
> radiobox because it needs a small "isVisible" piece of state. This has
> nothing to do with the business objectives of that UI. It is just a piece
> of transitory, accidental information. The same with an accordion, a
> datepicker or a slider. These cannot be used as pleasantly as regular
> elm-html components.
>
> elm-mdl has that closure property. One could create components that
> combine and behave like elm-mdl components.
>
> And there is no official, blessed alternative that would have this
> property for components that need a little bit of state.
>
> When I first saw the Elm Architecture I thought that it will evolve into
> something like a component architecture. In my naivety I thought that we
> will get some kind of function that would take a model, update and the view
> and would output some kind of component that would be usable in place of
> any other elm-html component. And the state would be sanely managed by the
> runtime with messages and all will be well.
>
> The elm-parts part of elm-mdl kinda does what I imagine that Elm
> Architecture would evolve into. I'm not referring to the implementation
> details of elm-parts. I'm referring to the stuff like this line:
> https://github.com/debois/elm-mdl/blob/master/src/Material/Button.elm#L417
> a call that would just wire things together 

[elm-discuss] Elm, Objects and Components

[Peter Damoc]

Evan points out that people would consider thinking in terms of Objects for
certain parts of the UI as a bad idea
https://youtu.be/LCNs92YQjhw?t=1340

he also points that Components are more or less the same thing and that we
should move away from thinking about them.

The  way I view it, the core idea behind Components is the closure property
that professor Abelson speaks about here:
https://youtu.be/2QgZVYI3tDs?t=2194

Building complexity by combining things and getting the same kind of thing
that can then be used to combine with other things.

The sidebar would be a *thing, a widget, an object, a component. * Now I
could implement it right now by using the components of elm-html and have
that component be a simple function where some elm-html widgets are
combined in a certain way.

The problem is that *some of the components* that are needed in a modern UI
need small state. If these components are implemented in C++ and wrapped by
the virtual-dom, we are lucky, we can use them. If they are not, we are out
of luck. Even a humble dropdown cannot be used as pleasantly as a radiobox
because it needs a small "isVisible" piece of state. This has nothing to do
with the business objectives of that UI. It is just a piece of transitory,
accidental information. The same with an accordion, a datepicker or a
slider. These cannot be used as pleasantly as regular elm-html components.

elm-mdl has that closure property. One could create components that combine
and behave like elm-mdl components.

And there is no official, blessed alternative that would have this property
for components that need a little bit of state.

When I first saw the Elm Architecture I thought that it will evolve into
something like a component architecture. In my naivety I thought that we
will get some kind of function that would take a model, update and the view
and would output some kind of component that would be usable in place of
any other elm-html component. And the state would be sanely managed by the
runtime with messages and all will be well.

The elm-parts part of elm-mdl kinda does what I imagine that Elm
Architecture would evolve into. I'm not referring to the implementation
details of elm-parts. I'm referring to the stuff like this line:
https://github.com/debois/elm-mdl/blob/master/src/Material/Button.elm#L417
a call that would just wire things together and give me the thing that is
the same as the rest of the things.

I think that solving the need that prompted elm-parts would basically mean
solving the Components issue.

What am I missing here? I understand that this is a complex issue but why
is this particular *need of a nice way of combining things that have
behavior* not being addressed?

I'm seeing the word *state* thrown around a lot but seriously, has state
been shown to be an issue in an Elm program? (I'm talking real issues with
a SSCCE attached not hypothetical stuff). I understand how this can be a
problem in a language with imperative execution and global state but even
in those languages if care is taken for state to be localized, things are
manageable.

Why not have some kind of automatic state management for these widgets?

-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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