However, I had been using Cmd as the vehicle to get the messages back to the top of the application.
On Thu, Aug 18, 2016 at 12:46 PM, Kasey Speakman <[email protected]> wrote: > You could be right. I'm thinking of back-end systems where a PM may need > to send a command to an "external" system (or even calls to its own system > are done as "external" calls), so I/O is involved. Maybe that scenario > doesn't apply on the front-end. > > On Thu, Aug 18, 2016 at 9:32 AM, Marco Perone <[email protected]> wrote: > >> Thanks Kasey for your observations! >> >> I agree with everything except for one thing. Regarding `process`, I >> don't think it should return a Cmd Command. Cmd generates asynchronous >> operations, and we receive a notification when they are completed, so I'd >> rather represent this message with an Event. I guess that `process` should >> return something like Command | Cmd Event, to allow both synchronous and >> asynchronous commands >> >> >> On Wednesday, August 17, 2016 at 9:31:02 PM UTC+2, Kasey Speakman wrote: >>> >>> So, reading through your implementation: >>> >>> Bug: In `projection`, you're doing a foldl on your history, but you're >>> putting new events at the head of your history using cons (::). So your >>> history be replayed in reverse order. I think there was a quite humorous >>> Red Dwarf episode about that. >>> >>> Possible typo: `process` should return a Cmd Command instead of Cmd >>> Event if we're talking about the Process Manager pattern. I would also do a >>> List instead of Maybe. (You can Cmd.batch them, and Cmd.none is actually >>> implemented as Cmd.batch on an empty list) >>> >>> Also, `process` is called incorrectly if it only uses Events to make >>> decisions. It should be called with all history, not just the events >>> generated from the one command. With only current events, it might be >>> missing the information needed to know if a Command is warranted. RPG >>> example: your game didn't have full history, so even though you got a >>> GoblinSlayer sword 5 minutes ago, it didn't on turn Glow on when >>> GoblinsEnteredTheArea. >>> >>> `commandHandler` - I believe the definition of commandHandler as >>> `Command -> Events -> Events` is too narrow. A command handler is often >>> responsible for wrangling external resources (e.g. API calls). The only way >>> to make this possible is to return `Cmd Events`. I also imagine it possible >>> to perform some IO through Cmd and subsequently need to issue another >>> Command to do something else with logic or IO. (Generally, I think multiple >>> API calls would be handled better by an API gateway, but I wouldn't want to >>> limit possibilities here.) I think Cmd Msg or Cmd (List Msg) would be more >>> expected here. >>> >>> As previously mentioned, I don't think it's a good idea to carry around >>> the increment value and actually calculate it in the `eventHandler`. The >>> relating of Incremented to the plus operator and Decremented to minus is >>> logic, and logic should be under the command handler. Updating a model with >>> event data should be as dumb as possible, because it should not have the >>> possibility to fail when simply responding to facts. Not sure if plus/minus >>> overflow in Elm (in JS, they flip sign on overflow), but other kinds of >>> operators could. >>> >>> On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote: >>>> >>>> Hi! >>>> >>>> I was eventually able to read carefully the thread and give some >>>> thoughts about it. >>>> >>>> @kasey, I had a look to your Gist and it looks really interesting! Some >>>> notes about it: >>>> >>>> - I think it would be better to store in the parameter of the Fact's >>>> the increment, and not the state of the application. It looks to me that >>>> you are mixing two concerns, i.e. the state of the applications and the >>>> events that happens to it >>>> >>>> - if I'm not mistaken, from you implementation it seems that only Act's >>>> (and not Fact's) can generate new Cmd's. I think that is some applications >>>> there could be the need to react automatically with a new Cmd to some >>>> events that happened >>>> >>>> To make everything clearer in my mind, I wrote my own implementation of >>>> something similar to what you did. You can find it here: >>>> >>>> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm >>>> >>>> It should be just a functional transposition of a standard es/cqrs >>>> architecture (I actually used also es/cqrs jargon), adacted to the Elm >>>> Architecture. >>>> >>>> I'd really like to know what you think of it. Let me know if something >>>> is not clear enough >>>> >>>> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote: >>>>> >>>>> So, I made a Gist >>>>> <https://gist.github.com/kspeakman/109475ecdd3068a022b59f7f73c9485a> >>>>> of the helper stuff which splits Facts and Acts. I call the helper >>>>> Factor... (Fact or Act ~=> Factor). There is a subsequent comment with an >>>>> example program explaining the helper's usage. >>>>> >>>>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Elm Discuss" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/elm-discuss/yKRYkoiQmPs/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
