1.9.1 and Knockout.js ViewModel binding appears broken

bdetchison

I believe the 1.9.1 update has broken interoping with Knockout.js viewmodels

I have set up 1 jsfiddles 1 for 1.9.0 and 1 for 1.9.1;

1.9.0 seems to work fine with Knockout.js I have a jsfiddle here. http://jsfiddle.net/bdetchison/b4SsE/.
1.9.1 seems to not update when Knockout.js's ViewModel has changed. Here is a jsfiddle. http://jsfiddle.net/bdetchison/27DZR/


**Edit
moved to bug reports

allan

Hi,

The 1.9.1 link had a 404 error on it when trying to load the DataTables source. That resulting in a JS error when the KO binding tried to initialise the table. I've just updated the 1.9.1 example with a link to the 1.9.1 source and it seems to work as expected: http://jsfiddle.net/27DZR/3/ :-)

Let me know if you have any other issue with it!

Allan

bdetchison

Doh! Looks like I boned my jsfiddle example. I am still having issues in my real app, but I haven't got back to it yet. I will get back to it tomorrow and see if I can resolve it.

Thanks!

bdetchison

Ok, I got back to this. Actually if you look at the example you created in jsfiddle and hit the "TestUpdate" button, you will see the underlying ViewModel is updated but the Datatables doesnt reflect it, where as the 1.9.0 version does.

allan

The problem is caused by this commit during the 1.9.1 development cycle:
https://github.com/DataTables/DataTables/commit/814ce1f7d57c92cb543a1aa027fc5190f8929655

Removing that added line allows the knockout bindings to go back to how they were. Equally, if you modify a few lines before, where aDataIn is defined as an extended object - if you don't extend the object, then it works as expected in DataTables 1.9.1.

In retrospect I don't like that clone - it was there to match the slice() on the arrays, which in turn was there because fnRender can modify the source data (which I liked even less than slicing the array). I'm thinking of adding an option to DataTables to disable that clone, which would allow easier and tighter integration with libraries such as knockout and backbone. However, I'll keep digging and see if this is a bug or an unintended consequence and will require the new feature to address it.

Allan

allan

I've just opened a new issue in the Knockout DataTables' extension Github repo about this issue: https://github.com/CogShift/Knockout.Extensions/issues/9 .

The problem is detailed there, but basically my change is overwriting the bindings :-(. Needs some thought on the best way to do this (and I need to get my finger out and make some time to play with Knockout properly!).

Allan

bdetchison

Thanks for digging into this, I have been keeping an eye on the discussion there. I hope you guys can hash out a solution, I really dont want to have to hack something together outside of the 2, we are planning on heavy integration in our next version of our UI.

much appreciated!

allan

I'd be really interested if you could elaborate on your use of the two a bit, given that much of the functionality is duplicated between the libraries (not in a 1:1 sense, but similar). Is it mainly the data binding you are after?

Allan

bdetchison

Sure, bascially we want to use Knockout for the MVVM functionality since we are migrating to more of a jquery solution for the client-side so lots of javascript. Not only does it help us keep our js better organized, it allows us to have our controls subscribe to the viewmodel changes. Basically what we whant we really liked about datatables was the sorting/paging/search out of the box. (Nice bonus is you have the play nice with bootstrap functionality as well). We dont really want to use datatables to manage the data, we just want datatables to subscribe to our viewmodel.

Basically every one of our pages are going to have a knockout view model associated with it, in some cases more if we have single page apps. if we dont have the model binder (cogshift), if we had a row addition, for example, we would have to enter the row into the view model array and then add a row to datatables. Thats a bummer because the whole idea is the UI would sit on top of the VM and the only thing we would need to worry about is the VM, the UI updating would get taken care of by itself with KO observables.

To complicate things even further we are using a signaling framework (SignalR) to asynchronously update our viewmodel which in turn should update the datatable, but again the idea was signalr could just update our KO viewmodel and the ui would update accordingly.

Its beautiful to see all these technologies work together. :)

EDIT:

Just to clarify, with the 1.9.0 version the only thing we do is initialize datatables and use the VM to handle everything as far as updating/inserting/deleting the array that datatables is using.

[code]






[/code]

allan

I'm afraid the fact that it worked at all with 1.9.0 was fluke - not by design! Indeed, if you had ever called fnUpdate on a row/cell, it would have broken in just the same way that it is now. However, this is certainly something that I would like to see working nicely - so thanks for the input on how you are intending to use this.

So the main goal here is to use the observable objects/values - when you change a value, the value will be changed in the DataTables. Order, filtering and paging will all be done with DataTables - does that sound about right.

That sounds perfectly feasible :-)

Allan

bdetchison

I came back and checked on this thread to see if any progress has been made, and I realized I never answered your question! Yep that sounds right :).

allan

Heh no worries. I'm afraid I've not had any time to get going on this yet myself. Hopefully sometime soon!

Allan

allan

Bit of an update on this. I've just committed a number of changes into DataTables which I think should resolve this issue. I've added a rows().invalidate() method which will cause DataTables to read the information from the data source object again, and then use that latest data.

This I think is how DataTables will be able to integrate with Knockout and similar libraries. At least that's the plan. Haven't had time to test it yet, but invalidate() at least will be in 1.10!

The changes are in git if anyone is feeling brave - in the 1_10_wip branch. The API is almost complete now, so unit tests will follow shortly, and hopefully a release in a not too distant future. During the betas, I'll attempt to get an integration example with Knockout going.

Allan