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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

[elm-discuss] Elm, Objects and Components

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