"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.
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.
This has nothing to do with the business objectives of that UI. It is just a piece of transitory, accidental information.
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
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.
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, 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
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?
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?
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.
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.
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.
You shouldn't need Polymer. Just web components, which are a standard and implemented in most browsers (probably all browsers on which Elm runs).
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
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.
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.
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.
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?
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.
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.
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+unsubscribe@googlegroups.com.
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. :)
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!
Underexplored territory!
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.
--
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.
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. :)I just tried this and it worked. :)
- npm install Polymer
- Add <link rel="import" href="/node_modules/Polymer/polymer.html"/> to your index.html
- 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>- In your Elm code, run Html.node "my-element" [] []
--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.
--
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.
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. :)I just tried this and it worked. :)
- npm install Polymer
- Add <link rel="import" href="/node_modules/Polymer/polymer.html"/> to your index.html
- 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>- In your Elm code, run Html.node "my-element" [] []
--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.
--
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.
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.
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.
--
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.
--
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.
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.
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 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.
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.
I'm not sure what you mean there - what part about the status quo regarding form elements doesn't seem sensible?
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.
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
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.
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
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.
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
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.
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
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.
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. :)
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.