We Keep Coding

Knockout subscribe/event type system without observable?

I want to make use of the subscribe() function of knockout js to manually trigger an event at a certain point.
I could make an observable() and everytime put a GUID in there to trigger the scubscribe.
Is there a cleaner way within Knockout js to have a typical event-like structure?
Edit
Ok, apparently I can use observable.valueHasMutated() - might already a a bit cleaner that using a GUID.
Example
This is the behaviour that I'm looking for:
function Car()
{
var self = this;
self.onOpenDoor = ko.observable();
self.openDoor = function()
{
// using an observable / valueHasMutated for this feels a bit hacky
// is there an other way to use the underlying subscribe() system?
self.onOpenDoor.valueHasMutated();
}
}
var car = new Car();
// multiple subscribers
car.onOpenDoor.subscribe(function()
{
console.log('Do something');
})
car.o**nOpenDoor.subscribe(function()
{
console.log('Do something else');
})
car.openDoor();
I am aware this is not the default 'knockout' way to do stuff - that is not what this question is about.
Update
After #RoyJ's reference to Niemeyer's blog I went for this solution:
function Car()
{
var self = this;
self.onOpenDoor = new ko.subscribable();
self.openDoor = function()
{
self.onOpenDoor.notifySubscribers();
}
}

Update If you're just looking for clarity, you can use notifySubscribers instead of valueHasMutated. You might want to take a look at the base type of observables, ko.subscribable.
I would do it like this:
var vm = {
///...definitions...
openCount: ko.observable(0),
openDoor: function () {
vm.openCount(vm.openCount()+1);
}
};
vm.openCount.subscribe(function () {
///...do something
});
vm.openCount.subscribe(function () {
///...do something else
});
ko.applyBindings(vm);
Demo http://jsfiddle.net/uoqdfhdb/2/

Load up multiple remote data sources for knockout.js data binding

I'm working on a knockout.js wizard and need to get data from multiple remote data sources (via AJAX) before I can properly render the drop-down menus in the wizard.
Additionally, there are 4 dropdowns and while #1 and #2 can be loaded up first, #3 and #4 depend on the choices selected in the first two.
So far I've experimented with using jQuery promises and also just nesting data calls and their associated callbacks, but are there any better ways to structure my view model code for the wizard?
Below is some of the data loading code. I'm happy to provide more if needed.
var postobj = {
id: workoutId
};
var getWorkout = $.post("./RowingWorkouts/GetWorkoutUsingId", postobj);
var getDiet = $.post("./Diet/GetDietUsingId", postobj);
var getFeedback = $.post("./RowingWorkouts/GetWorkoutFeedback", postobj);
// When all three are successful - I haven't gotten the when syntax to actually work yet
$.when(getWorkout, getDiet, getFeedback).done(function (workout, diet, feedback) {
//each of the parameter is an array
renderCharts(workout[0], diet[0], feedback[0])
// Here are more dropdowns that depend on the choices from the above ones
self.suggestedWorkouts = ko.observableArray();
// pseudo-code for data call for getting suggested workouts
$.post("./RowingWorkouts/GetSuggested", { id: selectedOldWorkout }, function(result) {
self.suggestedWorkouts(result);
});
});
This goes several levels deeper, and I would prefer avoiding it if at all possible. Are there any design patterns I'm missing or is this plain coded wrong?

You can use lazy loading observable to get data into your viewModel observables, and computed to subscribe on load of the parent level observables.
function ViewModel() {
this.workout = ko.onDemandObservable(ViewModel.prototype.getWorkout, this);
this.diet = ko.onDemandObservable(ViewModel.prototype.getDiet, this);
this.feedback= ko.onDemandObservable(ViewModel.prototype.getFeedback, this);
this.suggestedWorkouts = ko.observable();
ko.computed(ViewModel.prototype.listsLoaded, this);
}
ViewModel.prototype.listsLoaded= function () {
if (this.workout.loaded() && this.diet.loaded() && this.feedback.loaded()) {
this.loadSuggestedWorkouts();
}
}
ViewModel.prototype.getWorkout = function () {
...
}
ViewModel.prototype.getDiet = function () {
...
}
ViewModel.prototype.getFeedback = function () {
...
}
ViewModel.prototype.loadSuggestedWorkouts = function () {
...
}

JavaScript external code for page and objects - Best practice

I have a few questions about Best Practises using javascript in external files and namespacing.
Let's have a namespace MyCompany, global configuration stuff, code for individual pages and maybe some "API"s.
var MyCompany = {};
Global configuration in HTML
MyCompany.root = "/";
Which approach is better
First
MyCompany.Page = {};
(function(ns} {
ns.init = function() {
var root = MyCompany.root;
ajax(root+"somepage.html");
};
}(MyCompany.Page.Home = MyCompany.Page.Home || {});
and in html use
<script>
$( function() {
MyCompany.Page.Home.init();
});
</script>
Second (Page as an Class and its instance)
MyCompany.Page.Home = function() {
var root = MyCompany.root;
this.init = function() {
ajax(root + "somepage.html");
};
};
in html
<script>
var page = new MyCompany.Page.Home();
$( function() {
page.init();
});
</script>
Submodules and Mixing API with Page javascript
If our Homepage has some reviews.
MyCompany.Page.Home.Reviews = function() {
this.init = function() {
load_stuff();
}
};
And now inside Page init use
MyCompany.Home.Page = function(data) {
var reviews = new MyCompany.Home.Page.Reviews();
this.init = function() {
reviews.init();
};
};
Could that cause troubles?
It's obvious that Reviews extends MyCompany.Home.Page, but MyCompany.Home.Page requires Reviews.
It shouldn't cause troubles if instance on MyCompany.Home.Page is created after MyCompany.Home.Page.Reviews are loaded, right? Because Reviews in fact will extend the function object, is that right?
I guess this depends on answer to first question.
It also could be
(function(ns) {
ns.init = function() { MyCompany.Page.Home.Reviews.init(); };
})(MyCompany.Page.Home = MyCompany.Page.Home || {} );
(function(ns) {
ns.init = function() { load_stuff(); };
})(MyCompany.Page.Home.Reviews = MyCompany.Page.Home.Reviews || {});
Also should I somehow separate API of Page javascript?
Such as
MyCompany.APIS.Maps = function(location) {
/* Private variables */
var _location = location;
/* Private functions */
function search_address(address) { .. do search .. }
/* Public interface */
this.search = search_address;
do some initialization ...
};
I'd be glad if anyone reads it all to leave some comment.
Thank you in advance.

Which approach is better? Revealing singleton module (first) or a constructor function/class and its instance (second)?
Depends on your use case. If you don't expect multiple page objects to exist at once (and you hardly seem to), the singleton (with an init function) is really fine. Everything else could be considered wrong or at least overkill.
Same thing holds true for your MyCompany.Page.Home.Reviews (or MyCompany.Home.Page.Reviews?) class module, of which you seem to need only one instance.
It shouldn't cause troubles if instance on MyCompany.Home.Page is created after MyCompany.Home.Page.Reviews are loaded, right? Because Reviews in fact will extend the function object, is that right?
Yes.
(function(ns) {
ns.init = function() { MyCompany.Page.Home.Reviews.init(); };
})(MyCompany.Page.Home = MyCompany.Page.Home || {} );
If you have that ns shortcut available, you should use it:
(function(ns) {
ns.init = function() { ns.Reviews.init(); };
})(MyCompany.Page.Home = MyCompany.Page.Home || {} );
Also should I somehow separate API of Page javascript?
For development: Yes, in every case. Each module should have its own file. When deploying, you might concatenate them together for faster loading, but that's a different question.

Should data load occur in model or viewmodel when using Knockout

Is it wise to put your ajax calls in your Knockout ViewModel or should it instead be placed in a Model? I've come up with a few approaches but none feel completely right.
Approach 1 - ViewModel Only
window.someDataVM = function() {
var self = this;
//used to enable loading indicator
self.pendingLoad = ko.observable(true);
self.myData = ko.observableArray();
self.load = function() {
//make ajax call and populate myData observable array
}
}
Advantages
Simplest code structure - easier to maintain
Disadvantages
No reuse for data retrieval
Approach 2 - Model and ViewModel With Callback
window.someDataVM = function() {
var self = this;
//used to enable loading indicator
self.pendingLoad = ko.observable(true);
self.myData = ko.observableArray();
self.load = function() {
someDataM.load(function(data) {
//populate myData observable array
});
}
}
window.someDataM = function() {
return {
load: function(callback) {
//get data via ajax and return via callback
}
}
}
Advantages
More code reuse on data retrieval (i.e. one place to load someData)
Simpler interface that approach 3
Disadvantages
Uses callbacks
Approach 3 - Model and ViewModel With Knockout Model
window.someDataVM = function() {
var self = this;
//used to enable loading indicator
self.pendingLoad = ko.observable(true);
self.myData = ko.observableArray();
self.load = function() {
someDataM.load();
}
someDataM.isLoaded.subscribe(function(isLoaded) {
if (isLoaded) {
//populate observable array
}
});
}
window.someDataM = function() {
return {
isLoaded: ko.observable(false);
items: [],
load: function() {
//get some data, populate items, set isLoaded
}
}
}();
Advantages
Doesn't use callback
Keeps data code centralized
Disadvantages
Will be complicated to have lots of data entry points (i.e. LoadById, LoadByName, etc, etc.)

I personally don't feel comfortable with self-loading VMs. Thus, I would recommend to load data (model) first, and then pass it to the VM.
Conceptually, it would be something like this:
function loadData() {
//load data, can be asynchronously. Then callback
callback(data);
}
function callback(data) {
var vm = new someDataVM(data);
//do something with VM.
ko.applyBindings(vm);
}
This kind of approach makes even more sense when VMs are created by other VMs (multi-screen applications). Also, this approach emphasizes on model-view-viewModel separation by making a chain of logical dependency:
View => ViewModel => Model
However, VMs can re-load data or make asynchronous calls on user interactions. e.g. user may click a button on the page which loads the current time again. These kinds of interactions will happen inside the existing vm obviously. But the question was related to initial load, which I approach this way.

Automatic _.bindAll() in backbone.js

Is there a way to automatically do an _.bindAll for a backbone.js object?
I was talking to someone a while ago and they said that there was, but I have no idea where to start looking.
Example:
var TheView = Backbone.View.extend({
initialize: function() {
// HOW CAN I AVOID HAVING TO DO THIS?---->
_.bindAll(this,'render','on_element_01_click', 'on_element_02_click');
},
events: {
'click #element_01': 'on_element_01_click',
'click #element_02': 'on_element_02_click',
},
render: function(){
return this;
},
on_element_01_click: function(){
},
on_element_02_click: function(){
}
}

Do this instead:
_.bindAll(this);
Will bind ALL functions in this view.

I've since learned of a easier technique if you want to build bindAll in to your views (which is handy for things like AJAX callback methods that aren't auto-bound the way event handlers are). Basically you just override the constructor to perform the auto-binding.
var BoundModel = Backbone.Model.extend({
constructor: function() {
Backbone.Model.apply(this, arguments);
if (this.boundMethods) {
_(this).bindAll.apply(this, this.boundMethods);
}
}
})
var SubclassOfBoundModel = Backbone.Model.extend({
boundMethods: ['handleFetchResponse'],
initialize: function () {
this.model.on('sync', this.handleFetchResponse);
}
handleFetchResponse: function() {
// this function is bound to the model instance
}
})
Of course if you just wanted to bind all your methods you could leave out the "boundMethods" part and just have:
constructor: function() {
Backbone.Model.apply(this, arguments);
_(this).bindAll();
}

I tried doing this myself and I was able to get it working with something like this:
function bindOnExtend(clazz) {
var originalExtend = clazz.extend;
clazz.extend = function() {
var newSubClass = originalExtend.apply(this, arguments);
var originalInitialize = newSubClass.prototype.initialize;
newSubClass.prototype.initialize = function() {
// The constructor will get broken by bindAll; preserve it so _super keeps working
var realConstructor = this.constructor;
_.bindAll(this);
this.constructor = realConstructor;
originalInitialize.apply(this, arguments);
};
return bindOnExtend(newSubClass);
};
return clazz;
}
var BoundModel = Backbone.Model.extend();
bindOnExtend(BoundModel);
var BoundView = Backbone.View.extend();
bindOnExtend(BoundView);
However, I wouldn't recommend it. Doing that will make closures for every single method on every single model/view/whatever you instantiate. Not only does that add a slight increase in overall memory usage, it also opens up the possibility of memory leaks if you're not careful. Furthermore, it makes your stacktraces several lines longer, as they have to wind through bindOnExtend.
In my experience, having to do "_.bindAll(this, ..." is worth the trouble because:
1) it makes my code more clear/obvious to anyone coming after me
2) it encourages me to qualify my bindAll, instead of just using the 1-arg form
3) I hate wading through long stacktraces
But, if you want it the above code should work.