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/

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

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

--

Dylan Sale

CTO - Enabled

enabled.com.au

08 8272 6658

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

 

--

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+unsubscribe@googlegroups.com.

[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').

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

[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 <myRadioButton> and then call node "myRadioButton" to create one. No C++ involved.

What's wrong with that?

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

[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 tags are stateful what do we do about that, without jumping down the rabbit hole of 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 <maxgol...@gmail.com> 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?

[Peter Damoc]

On Tue, Sep 20, 2016 at 4:29 AM, Ian Mackenzie <ian.e.m...@gmail.com> 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....@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 <myRadioButton> 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 <falling...@gmail.com> 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). 

[Richard Feldman]

 Or you can define a Web Component like <myRadioButton> 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?

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

--

[Peter Damoc]

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

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

--

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+unsubscribe@googlegroups.com.

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

[Gusztáv Szikszai]

I'm just to jumping in here, to say a couple of things.

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

Well that's not true, other then Blink there is no support http://caniuse.com/#feat=custom-elements so polyfills are needed which Polymer provides (and very hard to set up by separate pieces).

Also maybe you don't know but I've created Elm-UI just for the same reason: to quickly build stuff from the same components just like Bootstrap. And it solves many of the problems that seems you are facing, the downside of it is that it's not in the official repository because well it "doesn't play nice". It uses the standard TEA where components with their own state and I think that is just fine it doesn't need to be more simple or complicated then that. And the communication is solved by allowing the components to publish messages to anyone who is subscribing to them.

[Ambrose Laing]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

[Peter Damoc]

On Tue, Sep 20, 2016 at 2:36 PM, Ambrose Laing <akl...@gmail.com> 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. 

[Peter Damoc]

On Tue, Sep 20, 2016 at 2:30 PM, Gusztáv Szikszai <cyber....@gmail.com> wrote:

Also maybe you don't know but I've created Elm-UI just for the same reason: to quickly build stuff from the same components just like Bootstrap. And it solves many of the problems that seems you are facing, the downside of it is that it's not in the official repository because well it "doesn't play nice". It uses the standard TEA where components with their own state and I think that is just fine it doesn't need to be more simple or complicated then that. And the communication is solved by allowing the components to publish messages to anyone who is subscribing to them.

 

I know about Elm-UI, I actually looked a little bit at it when I evaluated the options I had when I started the projects who's death I documented in the other thread. 
To be honest, it felt even more riskier to go with that than it did to go elm-mdl. 

elm-ui project also shows the impact of not using an official way on contributions. A lot more people contributed to elm-mdl than to elm-ui.
Now, this might be because this is how you want it (similar to what Evan does for the core) but somehow I think that this might not be the case. 

[Max Goldstein]

If Elm provides an official way to use TEA in order to implement Custom Elements the discussions around Components will go away.

 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. 

Respectfully, the discussions around components keep happening because people start them. Asking "how do I have stateful components with closure/nesting" falls prey to the XY problem, and also misses a lot of the philosophy of language design that Evan has talked about, most recently in his elm-conf keynote. To paraphrase, Elm is a young language and we're more concerned with doing things right for the future than making a good language today. Another key quote from his status updates: choose not to block. Going around and demanding new language features that fit your style of code is not helpful.

And by the XY problem, once again I ask that if the fundamental concern is the statefulness of HTML tags like dropdowns, let's address that in another thread. Getting HTML to do everything it can do when managed by JS is a web platform concern. Let's come up with specific examples of things we can't do (not just can't do easily, can't do at all) with HTML inputs.

[Brian Marick]

On Sep 20, 2016, at 3:21 AM, Richard Feldman <richard....@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.

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

[Duane Johnson]

On Tue, Sep 20, 2016 at 8:34 AM, Max Goldstein <maxgol...@gmail.com> wrote:

Respectfully, the discussions around components keep happening because people start them. Asking "how do I have stateful components with closure/nesting" falls prey to the XY problem, and also misses a lot of the philosophy of language design that Evan has talked about, most recently in his elm-conf keynote. To paraphrase, Elm is a young language and we're more concerned with doing things right for the future than making a good language today. Another key quote from his status updates: choose not to block. Going around and demanding new language features that fit your style of code is not helpful.

FWIW, I appreciate Peter's questions, and I don't interpret "What am I missing?" and "Why not have...?" as demands. I like Evan's approach to language change and anticipate it will lead to a better Elm. As we gather the batch of problems that will lead to insight, I think the user stories and context around them are also important.

[Rupert Smith]

On Tuesday, September 20, 2016 at 12:30:03 PM UTC+1, Gusztáv Szikszai wrote:

Also maybe you don't know but I've created Elm-UI just for the same reason: to quickly build stuff from the same components just like Bootstrap. And it solves many of the problems that seems you are facing, the downside of it is that it's not in the official repository because well it "doesn't play nice". It uses the standard TEA where components with their own state and I think that is just fine it doesn't need to be more simple or complicated then that. And the communication is solved by allowing the components to publish messages to anyone who is subscribing to them.

I'm intrigued. How did you implement the component pub/sub bit? 

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

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

[Rupert Smith]

Found it:

https://github.com/gdotdesign/elm-ui/blob/master/source/Ui/Helpers/Emitter.elm

This looks very useful to me. 

[Richard Feldman]

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 <link rel="import" href="/node_modules/Polymer/polymer.html"/> to your index.html
3. Add this before the script that imports your elm.js: <script>
   // register an element
   MyElement = Polymer({is: 'my-element',
   created: function() { this.textContent = 'My element!'; }
   });
   </script>
4. In your Elm code, run Html.node "my-element" [] []

I just tried this and it worked. :)

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

[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 <jam...@gmail.com> 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...@googlegroups.com.

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

--

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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Richard Feldman]

No problem! Hope it works well. :)

On Tue, Sep 20, 2016 at 2:22 PM Peter Damoc <pda...@gmail.com> wrote:

Hmm... I tried integrating the icon-toggle-demo and, to my surprise, I got it working even if it's past midnight here and I'm dead tired. 

I need to explore this some more tomorrow. 

Thanks Richard! 

On Tue, Sep 20, 2016 at 7:24 PM, Richard Feldman <richard....@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 <link rel="import" href="/node_modules/Polymer/polymer.html"/> to your index.html
3. Add this before the script that imports your elm.js: <script>
   // register an element
   MyElement = Polymer({is: 'my-element',
   created: function() { this.textContent = 'My element!'; }
   });
   </script>
4. In your Elm code, run Html.node "my-element" [] []

I just tried this and it worked. :)

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@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...@googlegroups.com.

[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....@gmail.com> wrote:

No problem! Hope it works well. :)

On Tue, Sep 20, 2016 at 2:22 PM Peter Damoc <pda...@gmail.com> wrote:

Hmm... I tried integrating the icon-toggle-demo and, to my surprise, I got it working even if it's past midnight here and I'm dead tired. 

I need to explore this some more tomorrow. 

Thanks Richard! 

On Tue, Sep 20, 2016 at 7:24 PM, Richard Feldman <richard....@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 <link rel="import" href="/node_modules/Polymer/polymer.html"/> to your index.html
3. Add this before the script that imports your elm.js: <script>
   // register an element
   MyElement = Polymer({is: 'my-element',
   created: function() { this.textContent = 'My element!'; }
   });
   </script>
4. In your Elm code, run Html.node "my-element" [] []

I just tried this and it worked. :)

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.

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

[Richard Feldman]

Well said, John! Neatly sums up my thoughts on the matter. :)

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.

--

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...@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...@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...@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...@googlegroups.com.

[Rupert Smith]

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. 

[OvermindDL1]

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

[Mark Hamburg]

So, could this thread be summarized as recommending two essentially independent projects for "components" in Elm:

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

2. Provide a standard approach to building new web components using Elm.

Those two things would probably mitigate most of the issues. One would lose some opportunities for type checking as data was forced across a JavaScript boundary, but it would mean that you could use extended UI toolkits created with web components and you could extend such UI toolkits using Elm.

Mark

[Richard Feldman]

I wouldn't go that far. I would summarize it as:

1. Try using some Web Components in Elm and see how that feels compared to other approaches.

That's it. :)

Let's gather data on how that goes and let it inform where to go next!

[Rupert Smith]

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.

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

[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 <akl...@gmail.com> 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?

>> --
>> 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...@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...@googlegroups.com.

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

[Richard Feldman]

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

[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

To unsubscribe from this group and all its topics, send an email to elm-discuss+unsubscribe@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+unsubscribe@googlegroups.com.

[Richard Feldman]

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 <mhamb...@gmail.com> 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....@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 <maxgol...@gmail.com> 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...@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...@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...@googlegroups.com.

[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....@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 <mhamb...@gmail.com> 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....@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 <maxgol...@gmail.com> 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.

[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

[Richard Feldman]

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

On Fri, Sep 23, 2016 at 5:01 PM Mark Hamburg <mhamb...@gmail.com> wrote:

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 <mhamb...@gmail.com> 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....@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 <mhamb...@gmail.com> 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....@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 <maxgol...@gmail.com> 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...@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...@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...@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...@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...@googlegroups.com.

[Peter Damoc]

On Sat, Sep 24, 2016 at 12:20 AM, Richard Feldman <richard....@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. 

[Mark Hamburg]

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

[Richard Feldman]

Yep, very true. I would love for there to be a better solution for text fields in particular.

[Mark Hamburg]

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....@gmail.com> wrote:
>
> Yep, very true. I would love for there to be a better solution for text fields in particular.
>

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

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...@googlegroups.com.