Marionette.js Mediator ('global' commands vs app controller)

Question

I am currently migrating a large backbone application over to Marionette and am curious as to the opinions on what is a better design for mediating activity between modules.

I have an Application that have several Modules where an action in one module might cause activity to happen in other modules.

Since these all are coupled to the Application I could simply use the Wreqr interface where:

Module 1:

someActivity: ->
   App.vent.trigger("skyFalling")

Module 2:

initialize: ->
   App.vent.on("skyFalling", @closeOrSomething)

Module 3:

initialize: ->
   App.vent.on("skyFalling", @blinkRapidly)

---

Or would it be better to trigger an event in Module1 where the Application (or a controller tied to the App) listens and then calls the 'closeOrSomething' and the 'blinkRapidly' functions directly on the modules (since the App is aware of all the modules that it is loading).

Application:

skyFallingEventHandler: ->
   Module2.closeOrSomething()
   Module3.blinkRapidly()

Answer 1

I have the exact same quandary (and found this question googling for answers). On first read through my opinion was that triggering events on the modules themselves was the best approach on the basis that this loosens any coupling between the modules and other components. However, having given it more thought it seems that this is exactly what the Wreqr interface has been designed for, so actually my approach would be to use the aggregator to handle events. I’d be interested to know which approach you decide to take.

Answer 2

I also came across this googling for answers to this..

I would say that your second version is the way to go. I don't think Module 2, for example, should know that it has to listen to Module 1 events (if even through the app aggregator). If I were to use this module in another system.. that extra listening code doesn't make sense in the new context where I use Module 2. Put it on the application and call into the controller from there.

The following makes way more sense to me currently, and it's what I will go with.

Application

skyFallingEventHandler: ->
  Module2.closeOrSomething()
  Module3.blinkRapidly()

Answer 3

I like to have my cake and eat it too. What I do for these situations is have a real mediator. The app publishes an event that the sky has fallen. Other modules shouldn't have to listen as it's not really their business. I then create a plugin that glues the too. Listens for sky is falling, and directly calls the other modules.

What I like is this plugin is it's own module, which can sit at a top level near your app (probably inside a plugins folder). I create plugins for my app for all different glue behavior. It's very easy to turn off some of this if they are no longer needed, and easy to change as they are isolated, and easy to find as one file per plugin.