linkedinattic / backbone.tableview Goto Github PK

We'd love to be able to install and use via NPM, but you've not published it!

FYI, using Chrome 27 I wasn't able to run your demo without pointing the backbone.tableview.js file to somewhere that responded with the correct mime type (unlike github). Here's the error i got:

Refused to execute script from 'https://raw.github.com/linkedin/Backbone.TableView/master/backbone.tableview.min.js' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

Since the ordering of the incoming responses of parallel requests is unknown, and the table is updated when the 'reset' event is fired in the collection, it can reach inconsistent states.

We should only care about the last request (as per user input), and cancel/ignore the rest.

• https://github.com/linkedin/Backbone.TableView/tree/7ef217de153430b37ab11c5955ba572df41601d7/backbone.tableview.js
• SHA 7ef217d

It would be great if there was a way to configure/allow for pagination page indexes to be zero-based.

There are probably more elegant solutions, but my current workaround is to overwrite TableView.prototype.update like so:

TableView.prototype.update = function(replace, skipFetch) {
    this.$("tbody").removeClass("in");
    this.trigger("updating");
    this.updateUrl(replace);
    if (!skipFetch) {
      this.collection.fetch({
        // instead of "data: this.data", a function is called
        data: this.filterUpdateData()
      });
    } else {
      this.renderData();
    }
    return this;
};

I then can "fix" the view's page data right before it's sent to this.collection.fetch(), with a separate function:

TableView.prototype.filterUpdateData= function() {
    var updateData = _.extend({}, this.data, {page:this.data.page - 1});
    return updateData;
};

This causes the data.page property to be decremented by 1, right before being submitted to this.collection.fetch().

Do you have any better ideas for how this could be implemented?

Unless I'm mistaken, it seems that TableView in its current form is dependent upon the use of Backbone.History. Is this necessary?

For example, on line 113 in JS, in TableView.prototype.initialize():

TableView.prototype.initialize = function() {
//...
this.data = $.extend({}, this.initialData, this.parseQueryString(Backbone.history.fragment));

this code block is called without checking to see if Backbone.history exists.

Yet elsewhere in the code, in TableView.prototype.updateUrl() (line 193 in JS):

TableView.prototype.updateUrl = function(replace) {
//...
if (this.router) {
    uri = Backbone.history.fragment;
}

You check for the existence of this.router before attempting to access Backbone.history.fragment.

Is the use of Backbone.History necessary for TableView, and if not, can this issue be corrected?

I "fixed" this by performing another check in TableView.prototype.initialize for this.router before merging data from this.parseQueryString(Backbone.history.fragment) into this.data. ex:

this.data = $.extend({}, this.initialData);
if (this.router) {
    this.data = $.extend(this.data, this.parseQueryString(Backbone.history.fragment));
}

• SHA: ce3bd56
• backbone.tableview.js: https://github.com/linkedin/Backbone.TableView/blob/ce3bd561e06b966aac0cfd4da336e8ea0de182b7/backbone.tableview.js

If the data size is too small say 4 entries, is there a way to set pagination to false ? it looks ugly on UI. having pagination which has nothing associate with it.

Can you please fix the demo? I'd like to see it!