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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
