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 <gurd...@gmail.com> 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+unsubscr...@googlegroups.com.
> 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