Autorun blocks

[SteveFortune]

Support the following sub config:

.state('module', {
  url: '/module/:moduleId',
  parent: 'organisation',
  abstract: true,
  template: '<ui-view/>',
  data: {
    $subs: [
        function() {
          return { name:'something', args: [Session.get('param'), 'param2'] };
        },
        ['$stateParams', function($aService) {
          return { name:'somethingElse', args: [Session.get('reactive'), $aService.dep()] };
        }]
    ]
  }
});

..and:

$subs.needBind($scope, function() {
  return { name:'something', args: [Session.get('param'), 'param2'] };
});

[SteveFortune]

SubStance should allow you to register (injectable) functions which return subscription payloads containing reactive dependencies (note the calls to Session.get). Internally, this is how we might manage them:

• We store these functions in a special list: _reactivePayloads.
• We have an internal computation registered which does the following: -- Iterates over the _reactivePayloads list, aggregating the results of all these -- Checks determines which current subs to stop and which to invoke -- Wraps the process of actually doing this in a Tracker.nonreactive block so that these subs aren't auto stopped on the next computation invalidation. This allows us to manage how the subs are cleaned up (i.e. in our deferred discard queue). -- I.e. we use this computation as an opportunity to reassess which subscriptions should be open and which should be discarded
• Whenever a new reactive payload is registered we invalidate the main computation
• We will probably have to mark the subs managed here with a $$autorun property, so we can tell whether they should be actively discarded as part of the autorun migration.

[SteveFortune]

I think we should also consider decoupling the subscription store from $subs. We could have a $subRepo service will the following methods:

• exists(key)
• discard(key)
• add(payload)
• existsAndKeep(key) \ atomically tests whether a subscription still exists for a given key and keep it if it does ?

This might manage the queue internally. The $subs would just be responsible for deciding when to post add and discard messages to the repo.