Re: [elm-discuss] Re: Basic behavioral composition

2016-09-05 Thread Rex van der Spuy
Hadn't noticed this section in the guide before. Great explanation > ... It's just been added :) -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elm-discuss] Re: Basic behavioral composition

2016-09-05 Thread Wouter In t Velt
Hadn't noticed this section in the guide before. Great explanation! Thanks for sharing. Op vrijdag 2 september 2016 18:00:31 UTC+2 schreef suttlecommakevin: > > This new doc helps a ton. Thanks for this! > > http://guide.elm-lang.org/reuse/ > -- You received this message because you are

Re: [elm-discuss] Re: Basic behavioral composition

2016-09-02 Thread suttlecommakevin
This new doc helps a ton. Thanks for this! http://guide.elm-lang.org/reuse/ -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elm-discuss] Re: Basic behavioral composition

2016-08-23 Thread suttlecommakevin
Yes, a wonderful and much appreciated breakdown, @debois. Couldn't have said it better @Wouter. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elm-discuss] Re: Basic behavioral composition

2016-08-23 Thread Wouter In t Velt
Thank you for this very clear and concise description @debois! Coming from React+Flux, I've followed much of the discussions on child-parent communication, components etcetera, but I found it really hard to scale in elm. The "everything is a component" from react is a hard habit to break, and

Re: [elm-discuss] Re: Basic behavioral composition

2016-08-20 Thread debois
This is a great question! Without internal state I think the most productive way of working with Elm is to avoid trying to generalise and stick with expressing yourself directly in elm-lang/html whenever possible. If you find yourself doing something a lot, use helper functions to construct

Re: [elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread Max Goldstein
As much as I love "don't overengineer it" as a principle, I'm not sure Richard's suggestion solves OP's problem. We want the possibility of NO label or NO icon, not just custom values. So that implies Maybe values in the record. Except, that opens the possibility of having neither an icon nor a

Re: [elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread OvermindDL1
Precisely, the thing like `MyButton.label` would return an appropriate instanced union holding whatever data you need. On Friday, August 19, 2016 at 12:58:10 PM UTC-6, Nick H wrote: > > I don't think Overmind's and Richard's inputs are at odds. Richard has > suggested an API. Overmind's code is

Re: [elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread Nick H
I don't think Overmind's and Richard's inputs are at odds. Richard has suggested an API. Overmind's code is what might fit into "-- Implementation goes here". On Fri, Aug 19, 2016 at 11:52 AM, Richard Feldman < richard.t.feld...@gmail.com> wrote: > `elm-mdl` is doing it that way because it is

[elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread Richard Feldman
> > `elm-mdl` is doing it that way because it is trying to follow how Google's > material library works, and since there is no way to introspect into the > virtualnode's to change how they act then it has to wrap things up in that > pattern, I.E., VirtualNode limitations and Html.Attributes

[elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread OvermindDL1
`elm-mdl` is doing it that way because it is trying to follow how Google's material library works, and since there is no way to introspect into the virtualnode's to change how they act then it has to wrap things up in that pattern, I.E., VirtualNode limitations and Html.Attributes limitations

[elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread Richard Feldman
This is a great question! I think there's a very clear answer here: *Don't overengineer it.* As you noted, this is basic - *super* basic - so by default, the best solution is also super basic. There's a button with 2 configurable options? Cool, let's write a function that accepts that

[elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread Max Goldstein
It sounds like you want a union type to represent the three possible buttons. You can have a view function that does case analysis and renders each possibility. Any shared code can be moved to a "let" definition, or another function. I mean, unless in missing something... -- You received

[elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread suttlecommakevin
Very interesting, thank you. Can you explain a bit more on the motives of that architecture and API, please? https://debois.github.io/elm-mdl/#buttons https://github.com/debois/elm-mdl/blob/master/demo/Demo/Buttons.elm On Friday, August 19, 2016 at 2:00:20 PM UTC-4, OvermindDL1 wrote: > >

[elm-discuss] Re: Basic behavioral composition

2016-08-19 Thread OvermindDL1
You could invert it to compose instead of extend, so something like this: ```elm -- Button with a Label MyButton.view [ MyButton.label "blah" ] -- Button with an Icon MyButton.view [ MyButton.icon "iconId" ] -- Button with both MyButton.view [ MyButton.label "blah", MyButton.icon "iconId" ] ```