You use this function: http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-App#map
Specifically, Html.map EventAction (Counter.view model.counter) This will let you transform your Counter.Event values into Action values. You give your function a transformer function of type (a -> b), in this case, the EventAction constructor, which turns an Events into an Action). Then you give it a piece of Html with messages of type a, and it will return an Html with messages of type b. On Sat, Aug 6, 2016 at 10:09 AM, FerN <[email protected]> wrote: > Thank you for your feedback Joey. > > I haven't though about inference consecuences at all. But I see the point. > Regarding your suggestion to create a new Tag: > > On the one hand: > How would I go embedding the Counter.view in my Main.view? > Since Counter.view propagates Counter.Events and not Actions, the only way > a can think of to bypass this restriction is to change my Counter package > to import the Main.EventAction Tag and always encapsulate any > Counter.Events inside this Tag before propagation. > If this is the case, I hope you see the problem. Now our Counter package > is not generic anymore. > > On the other hand: > This approach requires us to keep adding Tags for every new component we > want to introduce (although I can't say my proposal solves or eases this > particular aspect either.) > > Thank you for suggesting those threads too. I will keep an eye on them. > > > El sábado, 6 de agosto de 2016, 18:46:28 (UTC+2), Joey Eremondi escribió: >> >> Hi Fernando. Thanks for your input! A few things: >> >> 1. Why can't you just do this: >> type Action = LoginOut | EventAction Events >> >> i.e. you create a new tag for Action that lets you use an Events >> >> >> 2. Do you know how this will affect type inference? Elm's type system is >> nearly maximal, in the sense that adding features usually breaks inference. >> This almost certainly will, since it introduces subtyping. Look at this >> example: >> >> case x of >> Increment -> 3 >> _ -> 0 >> >> What is the type of x? In Elm, we can tell from the tag that it's an >> event. Here, we can't tell if it's an Event or an Action. We'd then need >> some notion of a subtype, which usually doesn't play well with inference. I >> don't know if this flavour of subtyping is undecidable, but my gut says it >> is. >> >> 3. You should probably follow these threads on Elm-dev: >> https://groups.google.com/forum/#!topic/elm-dev/klu1gg7Snwk >> https://groups.google.com/forum/#!topic/elm-dev/B3knsc7tv50 >> >> >> >> On Sat, Aug 6, 2016 at 8:57 AM, Fernando J. Naranjo Talavera < >> [email protected]> wrote: >> >>> Hello everyone. >>> I have been experimenting with Elm language for some weeks now, mainly >>> in the areas of Styling and Composition. >>> In all this time I have been struggling to find a suitable solution for >>> Composition and Separation of concerns in Elm when it comes to Medium / >>> Large projects. >>> Sadly, what I have found is that (the in all the other respects >>> *excellent*) Elm type system and architecture, always stands in my way. >>> >>> >>> I have pushed a really small Elm project to GitHub in which I have tried >>> to settle what (IMHO) would be an interesting addition to the Elm language: >>> The ability to Combine/Compose Union Types (not individual Tags) >>> >>> https://github.com/fejnartal/elm-utcombination >>> >>> This project is so tiny that, I believe, everyone should be able to take >>> a look a understand the kind of flexibility I'm trying to pursue. >>> So I would be very glad to hear your suggestions. >>> >>> - If you believe the language is already able to account for the kind of >>> abstraction I'm trying to build PLEASE, I would be very grateful to hear >>> about your approach to this problem. >>> - If you think you would end up using such a feature, that would be >>> great news. And also, any suggestions or drawbacks that you may have >>> identified in t he proposal. >>> - Whatever you have to say. Thanks. >>> >>> All my career, I have been mostly an Object Oriented programmer and it's >>> only now that I'm beginning to learn and practice with functional >>> languages. So, it's quite possible that my OO mindset may be reflected in >>> the code. >>> >>> -- >>> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
