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 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.
