Question

I am struggling with a problem that keeps cropping up when working with the KnockoutJS framework and MVVM in general. There are times when a property on a specific item in a collection changes and because of that change, I need to affect all the other items in that same collection. In all languages and patterns, an object isn’t supposed to “know” anything about the collection it’s in, but I find myself needing to break that rule often to get certain kinds of logic to work.

I have created a contrived example of what I’m talking about to demonstrate the hacky sort of way I’ve been solving this problem. I’m hoping someone with more experience can weigh in and show me the better way to do this.

JSFiddle Contrived Example

Answer 1

I don’t know whether this is the "recommended" approach, but I will offer my advice of how I would tackle this issue. I am not a MVVM expert (though I’ve written quite a few KnockoutJS apps), but I think some OOP principles will be more than enough to help here.

So first let’s discuss the current state of things…

Your approach, as you correctly observed (knockout pun unintentional!), is not ideal – the Person objects are aware not just of their siblings (even if indirectly via a subscription) but also the parent object to which they are subscribing – Your Person type is subscribed to changes on the parent. Not only does this make your Person object unusable outside of this scenario, it also gives each instance too much responsibility (violating the Single Responsibility Principle) and each instance is subscribed to changes on every other instance, which is of course wasteful!

So what’s the solution?

To me the ideal place to put this kind of logic is on your parent object (i.e. your view model). Your view model already has knowledge of it’s child objects, so why not put the functionality there? This would make your Person type reusable elsewhere (OK so it has observables, so it’s tied to KO at the moment, but this can be overcome with the Mapping plugin) and relieves it of the responsibility of managing its siblings.

But still this means that you have tight coupling between parent and child – not what we want in OOP! To overcome this, you can adopt a pub/sub (observer) pattern and have your Person type publish a message whenever something changes, then you can let a subscriber (e.g. you view model) decide how to respond to this event. You need not necessarily use knockout’s pub/sub offerings either, any pub/sub implementation will do. Though you may as well take advantage of what KO offers, so I would point you in the direction of these extensions/helpers to ease things a little: http://www.knockmeout.net/2012/05/using-ko-native-pubsub.html

Hope I’ve been of help 🙂