0

Our durandal application has many modular UI components (all created using AMD constructor based viewmodels) and I would like to begin adding pub/sub communications. I need to determine the best way to ensure that subscriptions are 'cleaned up' properly.

When/how should these subscriptions be cleaned up?

The deactivate event seems to be sufficient for a select few viewmodels, but what about the rest? I don't see a particular mechanism which would allow a viewmodel to reliably 'clean up' after itself.

Before I go implementing some sort of disposable pattern, is there some obvious approach I'm missing here?

Followup question: Is there anything to be done other than calling subscription.off() to properly clean up?

Shaun Rowan
  • 9,269
  • 4
  • 28
  • 52

1 Answers1

1

Calling subscription.off() from deactivate when working with view models or from detached when working with widgets should be all that's required. The event system has a bunch of test cases https://github.com/BlueSpire/Durandal/blob/master/test/specs/events.spec.js#L240, which could be used as starter for your own testing.

RainerAtSpirit
  • 3,723
  • 1
  • 17
  • 18
  • As good an answer any I suppose. Those approaches don't really work well for non-widgets which don't participate in routing though (which is a ton of use-cases) – Shaun Rowan Jan 23 '14 at 19:58
  • This has nothing to do with routing per se. As long a views are created by an activator (http://durandaljs.com/documentation/Using-Activators/), either by using `router` or by creating your own manually `deactivate` will be called. Feel free to to create a use case using https://github.com/dFiddle/dFiddle-2.0 for those were this is currently not working. – RainerAtSpirit Jan 23 '14 at 20:52