The bit I love about the Elm Architecture that I really wish existed in other frameworks is the "Command" system, by which the "Update" step can dispatch further changes. Basically, imagine if a Redux reducer could dispatch further actions.
I've tried building Redux apps with bidirectional real-time communication (re: networked video games), and found myself having to pull almost all of the logic up to the action layer, as I often needed to dispatch further side effects based on changes that happened as the result of an action. It made my reducer into nothing more than a dumb setter, and caused me to have to write complex mocked tests for my action layer instead of my reducer layer.
I know there's been some attempts at bringing this to Redux (such as https://github.com/redux-loop/redux-loop), but from what I've seen it isn't quite as easy to use.
OTOH, I will say, as an outside observer, it sounds like Elm has run into problems with this approach (see: the removal of WebSockets from this guide, pending a rewrite), so I am curious to know more about what issues arose.
I've tried building Redux apps with bidirectional real-time communication (re: networked video games), and found myself having to pull almost all of the logic up to the action layer, as I often needed to dispatch further side effects based on changes that happened as the result of an action. It made my reducer into nothing more than a dumb setter, and caused me to have to write complex mocked tests for my action layer instead of my reducer layer.
I know there's been some attempts at bringing this to Redux (such as https://github.com/redux-loop/redux-loop), but from what I've seen it isn't quite as easy to use.
OTOH, I will say, as an outside observer, it sounds like Elm has run into problems with this approach (see: the removal of WebSockets from this guide, pending a rewrite), so I am curious to know more about what issues arose.