Graph3d setOptions throws exception setData does not exist

[DaveWare]

I just started trying to use Graph3d yesterday and used the available example code 10_styling.html to reproduce the excpetion. Btw; nice work! I changed the example to call setBarWidth() when x or y width is changed.

I cloned the latest repository and am using the distribution:

• @Version 4.20.1
• @Date 2017-07-02

I wanted to allow the users to dynamically set the value range for coloring. When I pass updated options to graph3d.setOptions() an exception is throw from DataGroup.reload line 13850 that says DataGroup does not have a setData method. I changed reload to take a graph3d as an argument and called graph3d.setData(this.dataTable) rather than this.setData(dataTable). This seems to have the correct behavior. The graph updates and has the new value range. Or in the case of the example code below the correct bar width.

Not sure if this would be the proper fix as I have just started looking at your component.

Object doesn't support property or method 'set

  /**
   * Reload the data
   */
  DataGroup.prototype.reload = function () {
    if (this.dataTable) {
      this.setData(this.dataTable);
    }
  };

10_styling.html
10_styling.txt

[wimrijnders]

OK, great, a Graph3D issue. I would be happy to help, but would you mind cleaning up your comment a bit? Seems like some text is missing. I cleaned it up as far as I could.

[wimrijnders]

I think you're on to something here. I must have missed this in the refactoring to DataSet. I'll look at it in depth tomorrow. Thanks for reporting!

[wimrijnders]

Confirmed. This is a silly oversight. I owe you a beer for finding this.

Your fix works, but I find it a very roundabout way of setting the data. I propose the following, which will do exactly the same thing:

/**
 * Update the options. Options will be merged with current options
 *
 * @param {Object} options
 */
Graph3d.prototype.setOptions = function (options) {
...
  // re-load the data
  //this.dataGroup.reload();
  var dataTable = this.dataGroup.getDataTable();
  if (dataTable) {
    this.setData(dataTable);
  }
...
};

This gets rid of the dependency to the Graph3D instance within DataGroup. In fact, DataGroup.reload() can just plain die now.

I'll make a PR for this. Again, thanks for reporting.

[DaveWare]

I like your fix much better. The circular dependency mine introduced was not good. Thanks for the quick fix!

[wimrijnders]

My pleasure, but for completeness I will state that what I offered you was a workaround; the fix is forthcoming and will be in the next release.

The circular dependency mine introduced was not good.

Indeed, but that was not your fault, the circular thing was already there. Best to kill it right away, before my eyes start to bleed.

[DaveWare]

A quick follow up to let you know I am trying to update the bars to reflect data that is changing regularly. When I updated the VisDataSet the 3D graph was not responding. I tracked it down to the subscriptions getting corrupted somehow because of the workaround. It seems that the ‘*’ is unsubscribed via .off and then subscribed via .on. When this happens for some reason it loses the subscribed method _onChange that begins at line 13628 of vis.js. // subscribe to changes in the dataset var me = this; this._onChange = function () { graph3d.setData(me.dataSet); }; this.dataSet.on('*', this._onChange); I didn’t track it down further because when I took the workaround out to test the updates and found that most of the time I was having to replace over 90% of the values. So it was much faster to just setData(data) and replace the entire dataset rather than update the individual values. Replacing the values took 2-3 seconds to update the 3d bar chart for a 10x10 dataset where as setData with a new dataset was instantaneous. Just thought I would let you know so that you can watch out for this when you do the proper fix.

[wimrijnders]

Thank you for your attention; I see the problem, it's in DataGroup.initializeData() where _onChange() is stopped before the guard checks for input run. I'll take this along in the pending PR I'll make a new PR for this.

I would say that your solution is appropriate here. The reason that incremental updates take longer is that the graph is redrawn after every change. There are several ways around this, but your solution is by far the simplest.