Cell dependencies

Tags: #<Tag:0x00007f8b25b962e0>
#1

I have a table which has rows with dependent rendering of values, something like:

[STATUS, VALUE]

Where STATUS could be “On” or “Off”. If “On” then VALUE should show (it’s a number), if “Off” then VALUE should be hidden, but not actually cleared. Simply changing STATUS on a row should update the display of VALUE for that row.

So I made a renderer for the VALUE column like this:

function valueRenderer(instance, td, row, col, prop, value, cellProperties) {
  Handsontable.renderers.NumericRenderer.apply(instance, arguments);
  if (instance.getDataAtRowProp(row, 0) == "Off") {
    td.innerHTML = "";
  }
  return td;
}

This works, and to my surprise changing the STATUS seems to re-render the VALUE column for that row.
Example: http://jsfiddle.net/d2emkg0a/2/

This surprised me (in a good way, but I want to understand why), because I expected to have to write a trigger (say from afterChange) to update the VALUE column after a change to the STATUS column. Now I’m wondering why this works? Has my code somehow triggerd the table to re-render() after every change? Or does Handsontable track dependencies automatically when you call getDataAtRow during the renderer, so that it knows a change to col 0 requires redraw of column 1?

#2

Hi @abeall

The change of a state (cell value) triggers the renderer (without the renderer the change wouldn’t be visible). This change in your case calls the conditionalRenderer method.

Each data change calls a renderer. It happens even when the values do not need to be rerendered cause they are the same > http://jsfiddle.net/8zh0eq07/
The exception is metadata - http://jsfiddle.net/y5zyw0hy/ which do not trigger the renderer.

#3

Interesting, I didn’t realize that the table re-renders all cells when a single cell changes. That seems inefficient for performance, but it does seem to perform well. I guess that’s fine and makes the dependencies easy!

I thought maybe Handsontable was tracking cell access during the renderer call, similar to how MobX tracks state dependency.

#4

Yes, it is a huge performance blocker. That is why the formulas, filtering and searching work really slow when you have a larger dataset.

We’ll be changing this behavior but as this is a breaking change for the core we need to fix some smaller issues that are related first. Then get our hands on the updateSettings without which no settings can change and then… create a new renderer logic.

I thought maybe Handsontable was tracking cell access during the renderer call,

That is one of the approaches that we will need to check for the new renderer.

1 Like
#5

Good to know. I’ll be interested in the renderer re-write for performance, saw it on the board. Our dataset cap is 50,000 rows so we’re certainly interested in all things performance related.