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