IT:AD:Durandal.JS:HowTo:Navigation/Pass Data Around Between Views

Passing around entities between views is a slippery slope: pretty soon you have a Monolithic/ application – rather than it remain Loosely Coupled/.

In Durandal/, there are typically 3 approaches to sharing data between view models:

A route is registed that can take an argument ('/student/details:id'), so that the parent can call the second view as follows:

//From ViewModel
router.navigateTo("#/details/3");

or from View:

<a href="#/details/3"/>

and the second ViewModel/ retrieves the id from the context, and uses that to retrieve the record from a repository or other.

  model.prototype.activate = function (context) {
    //The context.id is what was gotten from the registered route in data/settings.js
    var nsn = context.id;
    this.record = studentService.getSingleByNSN(nsn);
}

It works, but only as long as there is a store of some kind to get the object out of. If you need to pass an in-mem/non-stored object, you have to use other options.

Process * Parent ViewModel gets the child ViewModel first, by requireing it (as a singleton, or a constructor, and creating one). * Pushing the data into it (eg: passing record from parent ViewModel/ to child ViewModel/.

ACiD/:

• Considerations:
  • Creates coupling between the two views.

passing in the data it needs. Typically here you would have a property on the parent that is the active child view model and compose this in the view. This approach creates coupling, but is OK in logically coupled scenarios.

EventAggregator: Pass the data through a mediator. Now we are only coupled to an event contract. The child must exist and be subscribed to the aggregator (ie, been loaded already).

ACiD/:

• Considerations:
  • Works as long as child view model is created before event is fired.

Both ViewModel/s shared the same context.

Process:

• Both Views require a singleton object, and pass variables to each other through that.

ACiD/:

• Advantages:

  • Removes coupling between the views.

  * Considerations:

  • Can only use the data model once (it's a singleton). If there was going to be more than one data model needed, a cacheService would be needed, passing the child object just the identifier of the object in the cache, for it to retrieve.

If the data changes faster than the lifecycle of the view model, combine this with EventAggregator to notify the view model of changes. This is a good approach to remove coupling between view models.

A variant of the Shared Singleton Model/ concept that I've seen is one where the caching service was an appropriation of the routeinfo object.

var route = ko.utils.arrayFilter(router.visibleRoutes(), function (route) {
                return route.name === 'student/details/:id'; 
             });
      route.settings.myObject = whatever;       
         

and pick up that object on the receiving view:

function activate(adata){
       var whatever = adata.routeInfo.settings.myObject); 
}
         

ACiD/:

• Considerations:
  • I'm intrigued, but I'm not sure what I think of it yet.

• https://groups.google.com/forum/#!topic/durandaljs/kGZSqT-4GBU
• http://stackoverflow.com/questions/16431512/durandal-multiple-master-pages/16472791#16472791