On Aug 17, 2016, at 4:25 AM, Oliver Searle-Barnes <oli...@opsb.co.uk> wrote: > > e.g. I'm using websockets to communicate with the server, in my previous > experience I would have implemented a Store of some sort which took care of > communication with the server and allowed the view layer to just worry about > asking for information and sending mutations.
I have similar concerns about how deep down the stack Elm can go. At some point, it seems like a good thing to separate business logic concerns from UX logic concerns. Managing complexity is one of the most important parts of doing software development. (Or is if you pay heed to Dijkstra.) These concerns aren't about Elm as a language but have to do with the monolithic architecture that Elm encourages. Types make viable larger programs than would seem reasonable with JavaScript, but at some there needs to be a way to separate concerns. I can see two potential answers within Elm. (There may be more but these are the ones that leap out.) One is that it could be that business logic belongs in Effects Managers. The documentation around Effects Managers, however, suggests that they should not be created all that often and that would be an odd stance for what would be a standard part of a larger program. The second is to put the business logic layer in as a wrapper around the view layer. That, however, requires a rethink of commands and subscriptions to embrace something more like the more general request concept with them really representing a request for the next layer up to do something or provide some information. Mark -- 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.
