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.
