Oh wow! This looks super cool! πŸ€“

…and it seems this would also cover for the issue that Peter mentioned 
<https://groups.google.com/d/msg/elm-discuss/ta64y4JBMc4/Y8PEUFDPCgAJ>: 
this gives me the ability to have a real onClick callback without 
pre-computing the expected-after-click state! 🀠 β€” Right Peter? πŸ€”

OK, this is good. I’m not sure if I want to completely move to this model 
right away β€” although Elm makes it easy to refactor in any way imaginable 
πŸ˜‰ β€” but it’s definitely useful to have it under my belt. πŸ€“

Thank you Mark! πŸ™‚

On Thursday, August 31, 2017 at 10:29:18 PM UTC+3, Mark Hamburg wrote:
>
> Your previous update structure was essentially (ignoring commands and 
> subscriptions)
>
> type Msg
>     = Set Model
>
> update : Msg -> Model -> Model
> update (Set newModel) model =
>     newModel
>
>
> used as something like:
>
> ... onClick (Set { model | counter = model.counter + 1 }) ...
>
>
> The revised approach looks like:
>
> type Msg
>     = Apply (Model -> Model)
>
> update : Msg -> Model -> Model
> update (Apply fn) model =
>     fn model
>
>
> used as:
>
> ... onClick (Apply (\model -> { model | counter = model.counter + 1 })) ...
>
>
> The point is that we avoid capturing the model value in the message being 
> routed around so that we can interleave this message with other 
> asynchronous responses.
>
> Again, as noted in my earlier message, this is not the Elm way and will be 
> unfriendly to tools like the debugger but it is valid Elm. It is somewhat 
> more complicated than the original version but still avoids the level of 
> indirection associated with messages. It is also more efficient than the 
> original form in that it at most constructs new function closures rather 
> than constructing entire new model values for each possible action in the 
> UX.
>
> Mark
>
> P.S. I was tempted to also include this form in the example:
>
> ... onClick (Apply incrementCounter) ...
>
> incrementCounter : Model -> Model
> incrementCounter model =
>     { model | counter = model.counter + 1 }
>
> But if one did that, one might as well have an IncrementCounter message 
> and handle it in the update function.
>
>
>
> On Thu, Aug 31, 2017 at 11:57 AM, Vlad GURDIGA <gur...@gmail.com 
> <javascript:>> wrote:
>
>>
>> On Monday, August 28, 2017 at 4:01:20 AM UTC+3, Mark Hamburg wrote:
>>>
>>> One other note: If you don't care about Reactor and the Debugger but do 
>>> care about async problems, you could get almost the same structure by 
>>> passing back Model -> Model functions instead of Model values.
>>>
>>
>> Sorry Mark, this sounds cool, but I’m kind of a slow thinker (generally) 
>> β€” could you give some pseudo-code to show an example of what you mean? 😊
>>  
>>
>>> Doing so may cause you to receive a visit from the Elm thought police 
>>> but it is entirely semantically viable within Elm (and it's what I could 
>>> imagine a lot of other functional languages doing by default).
>>>
>>> Mark
>>>
>> -- 
>> 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 <javascript:>.
>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to