Thanks a lot! It is in examples like this that a functional noob like me learns about how to exploit the functional goodness. And start programming on next level of abstraction. I am very keen on learning tools/patterns for creating higher levels of abstractions. I hate to repeat myself over and over. Removing duplicate code is not enough; there are patterns of functions/modules which are also repeated over. It is hard to spot them and even harder to find a decent abstraction. Add to it lack of background in functional programming.
I am aware that this approach is prone to premature abstraction/optimization. But regardless I would like to carry it out in my spare time to learn from it. Once again, Thanks a lot! On Wednesday, 25 January 2017 21:22:13 UTC+5:30, Peter Damoc wrote: > > > On Wed, Jan 25, 2017 at 8:17 AM, Maksim Demin <[email protected] > <javascript:>> wrote: > >> Thanks for the response, it totally works, and I definitely think it is >> cleaner than having to Html.map everything! I am still trying to fully >> understand what is going on, pretty new to Elm. I kinda get what you are >> doing in the update to map the command, >> >> ( { model | field2 = "2" }, Cmd.map cfg.lift pageTwoCmd ) >> >> but how does that happen in the view? How does this cfg.lift which >> is lift : Page1Msg -> msg work here? >> >> div [ onClick (cfg.lift <| DoSomething1) ] [ text model.field2 ] >> > > Sorry about that, my bad. It should have been > > div [ onClick (cfg.lift DoSomething1) ] [ text model.field2 ] > > basically, the view receives a function that knows how to lift the > messages of the SubModule to the message of the parent. If you have type > defined as > > type Msg > = Msg1 Page1Msg > > Msg1 is also a value constructor, in other words, a function that takes a > Page1Msg and outputs a Msg. This is why you can use it as cfg.lift > > > Now, the reason my code looked like that was because it started as: > > div [ onClick (cfg.lift << DoSomething1) ] [ text model.field2 ] > > and when I saw that not working, my mind produced the version with the <| > (my mind is weird sometimes) > > You need << (function composition) when the event handler receives a > function. > So, if you have a submodule message like `type Msg = UpdateNameField > String` and in the view you have an input event, it would look like > > input [onInput (cfg.lift << UpdateNameField)] [] > > if cfg.lift is *f* and UpdateNameField is *g*, then (cfg.lift << > UpdateNameField) is *h* so that h(a) = f(g(a)) > > I remember being new to Elm and finding function application (*<|* and* > |>* ) and function composition ( *<<* and *>>*) mystifying. > After seeing few more examples and reading through these functions > documentation > <http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Basics#%3C%7C> > my mind clicked and now I love them. > They can make the code very very readable. > > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- 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.
