On Monday, March 20, 2017 at 11:58:38 AM UTC, Eirik Sletteberg wrote: > > In larger Elm apps, it makes sense to divide Updaters so you can > package-by-feature. > For example, a single page application could have updaters like this: > > - Configuration updater > - Session updater > - User Profile updater > - User Settings updater > - Content updater > - Some other business specific updater > > The challenge is when there are dependencies between Updaters, for example > the User Profile model might need data from the Session model, the Session > updater might need to send messages to the User updater (Load user profile > when session is updated), or the Content updater may need to check for the > Session updater (get session ID to send as parameter to the API when > fetching content), or some business-specific updater may need to interact > with both the Content updater, the User updater, and the Configuration > updater. >
I would apply a technique similar to CRC Cards from OO design. Instead of Class-Responsibility-Collaboration, make it Module-Responsibility-Collaborations. You have got a fair idea of what the split of responsibilities into modules is (configuration, session, user profile, user setting, content, and so on). For each module it is worth also explicitly spelling out what its dependencies (Collaborations) are. Analyzed that way, you might find a more optimal grouping of the responsibilities into modules that gives you less of a dependency head-ache. Even though that grouping may no longer align with your first pass at splitting things up into a modular design, it may be a way to a better design. Occasionally I have had a module that produces 'out messages' to signal some condition that an update method higher up in the structure has to deal with, possibly even updating the state of some other module beneath it, so it is effectively a side-ways message. I can see that this is a bit of a draw-back that modular designs sometimes inevitably lead to. I am avoiding modularizing too early, and using Model-Responsibility-Collaboration to drive the split into modules in a more optimal way, or even deciding not to at all if makes it apparent that I can't find a good modular design. -- 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.
