Best practice: Knockout observableArray inplace Add/Edit

The scenario is familiar: you have an observableArray in the viewModel that you want to be able to push new items to, or perhaps modify existing elements. There are just tons of code out there how to do so, for example knockout official example pages.

However, by mimicking that pattern, the viewModel quickly turns into a huge chunk of pointer to “active” elements, methods for “start edit”, “stop edit”. In the project I’m working, we’re going to have three different list with this functionality and it would just be such an repetitive work and overly complex code.

Just to make things worse, let’s imagine you want an in place editable table, like this guy wants to. If you look at his markup, there is just too much happening there with brackets, dubble equal signs,… Ugh, from my point of view the markup is the most important thing to get understandable and that’s not it.

Here’s the problem

Meet the Offers, an array with stuff that I’m offering. Yep, you guessed right it is an observableArray. As an admin, I want to be able to add/remove/edit Offers in place.

What you might have seen around is that an offer is created from a function call like so:

function Offer(id,name, shortName){
     this.id = ko.observable(id);
     this.name = ko.observable(name);
 }

Somewhere in your markup you end up with a

<input type="button" data-bind="click:$edit">

That must correlate to method on your viewModel

var viewModel = new function () {
    var self = this;
    self.Offers = ko.observableArray([]);
    self.selectedOffer = ko.observable();

    self.edit = function (item) {
        self.selectedOffer(item);
    };
}

But, hang on you also want to show an input text field if you edit the current item, as opposed to a div/span if you don’t edit. So you need some more methods that I am only going to name:

  • isOfferActive (used in the foreach in markup to evaluate what to show)
  • saveOffer (used to set selectedOffer to null so that none is edited)

Here’s the solution

So what we want to do is putting some of the “is active” “is inactive” logic on the element itself (rather than a comparing method on the viewModel $root). In the light of what I wrote earlier about the module pattern and jasmine testing, I ended up with this class:

var Offer = (function () {
    var activeOffer = function() {};

    //CONSTRUCTOR
    var offer = function(name, productMasterId, active) {

        var self = this;
        activeOffer = active;
        self.Name = ko.observable(name);
        self.Id = ko.observable(productMasterId);

        active(this);
        self.IsActive = ko.computed(function () {
            return self == active();
        });

        self.IsNotActive = ko.computed(function () {
            return self != active();
        });
    };

    var activateOffer = function () {
        activeOffer(this);
    };

    var deactivateOffer = function () {
        activeOffer(null);
    };

    offer.prototype = {
        constructor: offer,
        activateOffer: activateOffer,
        deactivateOffer: deactivateOffer
    };

    return offer;
}())

What’s so great with this? Well, it it takes a pointer to an observable that is considered to be the placeholder for the “current” selected Offer. The offer is then responsible to either set itself as active (offer.activateOffer()) or deactivate (offer.deactiveOffer()). Note that this observable does not need to be attached to the viewModel, actually this is how i do the add:

var viewModel = new function () {

    var activeUnlockedOffer = ko.observable(""); //we do not even need to add this to the viewModel

    this.Offers = ko.observableArray();

    this.addOffer = function () {
        var offer = new Offer("", "", activeUnlockedOffer);
        viewModel.Offers.push(offer);
    };

    this.removeOffer = function (data) {
        viewModel.Offers.remove(data);
    };
}

As you can see the activeUnlockedOffer is just a local variable. No need to pollute the viewModel with that. The only additional methods in my viewModel is the add/remove – which I think suits there (it should not be at the Offer anyways).

Perk number two, the markup will be easier to read, look at this:

<button title="Edit" data-bind="click: $data.activateOffer, visible: $data.IsNotActive" />
<button title="Save" data-bind="click: $data.deactivateOffer, visible: $data.IsActive" />

Another sweet thing with this solution is that when I add another list off offers, let’s call it OffersOnSales I can decide if I should allow one editable row in the two tables (in that case I would initialize all offers with the same observable), or if I want to allow the editing of one OfferOnSale and one normal Offer (in that case I would initialize the different groups with different observables).

And… yes, there’s a jsFiddle to it. Happy coding!