Should be able to unapply bindings

[mberkom]

Knockout should have a complete method for unapplying bindings. I've written my own that seems to work fairly well and would like to see something similar integrated into the core.

// accepts jQuery node and remove boolean
ko.unapplyBindings = function ($node, remove) {
    // unbind events
    $node.find("*").each(function () {
        $(this).unbind();
    });

    // Remove KO subscriptions and references
    if (remove) {
        ko.removeNode($node[0]);
    } else {
        ko.cleanNode($node[0]);
    }
};

This is especially useful when setting up a Knockout viewmodel as a widget which can be added and removed dynamically.

[mbest]

Your example will not work if the "widget" contains control-flow bindings. It will "unbind" okay, but the resulting html may not be the same as the original. Knockout already has the with and template bindings to handle this sort of situation.

[mberkom]

with and template are both really useful bindings, but they fall short in certain situations. Specifically, they require directly coupled viewmodels and views. I'm looking for a pattern where models can be passed between two or more viewmodels and the viewmodels remain completely decoupled from each other. See aura for an example of what I'm getting at.

I've never tried to "rebind" the html after "unbinding" because I always remove the html.

[mberkom]

I've mocked up a quick example of how I'm using the method in combination with Ryan Niemeyer's ClassBindingProvider here: http://jsfiddle.net/mberkom/genXq/13/

[SteveSanderson]

Creating a way of removing bindings would be quite a significant change - it would mean that all existing bindings (including custom bindings) would need some extra callback function (e.g., dispose) to tell them to undo or release whatever non-GCable stuff they've created (e.g., event handlers, DOM data, etc.). Calling cleanNode alone isn't enough because the custom binding might have made additional changes elsewhere or applied delegated events elsewhere.

All that said, I can appreciate it would permit extra flexibility in some cases. I'll keep this issue report open as a possible future enhancement.

I've mocked up a quick example

Sorry, I didn't really follow what you were doing here or how it differs from usual patterns. Could you clarify?

[mberkom]

Sorry, I didn't really follow what you were doing here or how it differs from usual patterns. Could you clarify?

Yes, I can. Following the concept of large scale JS application architecture found here, I created an object I call the Knockout Module. It's a viewmodel wrapped with start and stop methods designed to insert the viewmodel, instantiate, and then remove it. My fiddle is an example of how it operates. I'm using the Class Binding Provider to keep the HTML clean and allow for better debugging.

By declaring a viewmodel with my Knockout Module pattern, it is now possible to insert an editing interface anywhere without requiring it to be nested beneath another viewmodel's bindings. See my question here for a possible application. I'm currently using it for loading a form to edit table rows.

[rmeschian]

Hi Steve,

First, thanks for an awesome library. We definitely need an uninit callback in bindings. I'm building a rich application where widgets are often created and destroyed (each widget is like a page, with ko bound data), so I need a way to clean up to avoid mem leaks.

Thanks!

[vicary]

+1 For a solution of mem leaks. Doesn't have to be a complicated unbind, or even reverting back to the state before binding. Just need a way to dispose things no longer needed.

[jelling]

+1 for this. I have situation where we have to pre-render the DOM elements to prevent locking up IE7/8. mberkom's function is a big help.

[jelling]

FYI, Mberkom's unapplybindings script is also excellent at reducing IE7 memory leaks. I added it to my page.unload and it helped a good bit.

[dnutels]

My concern for this mostly lies with clashes between KO and other frameworks - namely Backbone or jQuery. Having cleanNode remove all the bindings, including those that do not belong to KO creates a multitude of problems.

Simply put - using jQuery's on(event, root, function(){ ... }) to delegate events to the root and then applyBindings to that same root is doomed if there is a need to re-apply bindings as it would make calling cleanNode not feasible.

[jrsearles]

This appears to be very similar to issue #41.

[rniemeyer]

Closing. Conversation can continue in #41.