On Wednesday, August 17, 2016 at 1:15:49 PM UTC-6, Evan wrote:
>
> Warning, I have not read everything here. About ignoring commands though,
> think of the type of a Html.App.program
>
> program : { init, update, view, subscriptions } -> Program Never
>
> The essence of this is just a record. So you can wrap that record however
> you want. Say like this:
>
> myProgram : ({ init, update, view, subscriptions } as details) =
> { details | update = \msg model -> (fst (update msg model), Cmd.none) }
>
> Now you have programs that drop all commands.
>
> I'm in the process of revining elm-reactor to track history for exactly
> the kinds of things you have in mind (testing, etc.) and I am using this
> basic technique. Anyone can do this. You can write time-travel in pure Elm
> this way. Make the update log all the messages it gets.
>
This is what I do in my ProgramEx library to have the separate filtering
step, and is how I would imagine a thing like this thread would be done as
well, the API itself though still seems hard to get right. Hmm, an idea
though...
What if update was all just Cmd's, it did not return a model, but certain
commands would update the model. like using the `put` and `update` syntax
that I propose in the other thread, you could do something like:
```elm
# Example for a multi-counter where each has an Integer IDupdate : Msg -> Model
-> Cmd Msgupdate msg model =
case msg of
{- Example using Cmd.putModel -}
Increment id ->
Cmd.putModel
[Model.Fields.counter, Model.Counter.Key id]
( Just ( (Dict.get id model.counters |> Maybe.withDefault 0) + 1 ) )
{- Example using Cmd.updateModel -}
Decrement id ->
Cmd.updateModel
[Model.Fields.counter, Model.Counter.Key id]
(\t ->
Just ((t |> Maybe.withDefault 1 ) - 1)
)
```
That way both commands are commands, and model mutations are commands. A
benefit is since you know which are prev->next state updates (updateModel)
and which are purely 'set' updates (putModel) then you know how they could
be combined and simplify their storage accordingly. You could even not
have a `Cmd.updateModel` and instead require another command with a new
argument that then sets it via a Put, thus no functions would be stored at
the expense of another model-update message for updates (which is probably
better anyway for such tracking). As such the above Decrement would end up
being something like this for this specific case:
```elm
Decrement id ->
Cmd.msg (Increment -1)
```
--
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.
