I know just enough about Elm to be a true danger to myself and everyone in my immediate vicinity, so I am not sure if this is a good idea. However, even if it is not, I learned a few things while coding it up.
In any case, after finishing the Elm - Beyond the Basics exercises, I was toying with ways of making it easier for modules to talk to each other in a clean manner, and I hit upon the idea of doing a version of The Elm Architecture for modules, running inside the TEA loop. I'm sure this is not original but was wondering what other people thought and what suggestions for improvements they might have. https://github.com/RJWoodhead/elm-memo The basic metaphor is that your app is like a large company, and each module is a department. Now, if departments -- or even the Main office -- were allowed to stick their fingers into the workings of other departments, chaos would ensue. So instead, the departments use inter-departmental memos to keep each other apprised of what is going on, on a need-to-know basis. In the Memo Metaphor, Cmd Msgs are letters arriving from outside the company, and memos are internal discussions about how to respond to those letters. In the Memo metaphor: - Each module's state is only changed by the module itself. If another module (including the Main module) needs to make a change, it sends one or more memos. - The Main module handles initialization, the UI skeleton, and routing memos. It is largely boilerplate. - Memo routing is simply and clearly defined in the Main module; a memo can be sent to multiple modules, or a recipient can subscribe to a memo. The model can be tested to decide whether to route a memo, and custom routers can be defined to handle special cases (like Memos with parameters) - Memos are atomic; each Cmd Msg arriving at Main.elm's update function may end up triggering a cascade of memos, which in turn create new Msgs, all of which will be processed before the next Cmd Msg. - The order in which memos are processed is deterministic (and the list of Msgs that are processed is saved in the model for debugging purposes) - If the stack of memos gets too high (due to an infinite recursion caused by incorrect routing), the router declares a "memo blizzard" and gives up. -- 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.
