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 <mdem...@gmail.com
> <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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
