Polymer Array changes doesn't reflect in the chart

[hariprasadiit]

If we bind ploymer array property to the google-chart element, Initially it loads whatever data polymer array holds but subsequent changes to that array property doesn't reflect in the chart.

steps to reproduce:

1. bind array property to the google-chart rows property.
2. make changes to the array property by using polymer array mutation methods. i.e push,pop, splice.
3. Observer if the google-chart updates its rows data.

P.S : Tried calling redraw(), it didn't help

[wesalvaro]

Yeah... That's the currently working-as-intended behavior but I'm open to suggestions on how you would like to see it changed. One issue with slice listening is that it may cause unnecessary churn.
When altering chart data, many values may be changed at once. The DataView for the chart is only updated when the rows's (in your example) pointer is changed.

chart.rows = [];
chart.push('rows', myNewRow); // Does nothing.
chart.rows = [myNewRow]; // Updates the chart data.

Doing this will update the view for you.
Alternatively, if you want to update the view in place, you may access the DataView's view attribute and alter either the view or the underlying DataTable. After such changes, a call to redraw will work.

I have a changelist #164 to break out the data handling portion of the element which will allow us to create a better API into the data handling as well as making it more modular.

[wesalvaro]

It's worth noting, that force skipping dirty checking should work, too.

[hariprasadiit]

Thanks for the explanation.

One issue with slice listening is that it may cause unnecessary churn

This makes sense.

#164 is nice thing to have in google-chart. I was looking for this kind of data handling functionality when was going through the docs. Any update on when it'll be released?

[wesalvaro]

In short, whenever it gets reviewed.

But really, I think it makes sense to leave v1 as it is (all-inclusive-y) and save big changes like #164 for v2. I have started documenting my plans for v2 of the element here. If you want to take a look and let me know what you think, that'd be cool. I plan to continue development and testing, soon. It's essentially a revamp of #91, #100, and #164.

[wesalvaro]

Hey, I got the initial stuff (with the intended feature parity) working here. See if it works like you would think when using the google-chart-data element with rows and columns.

You should now be able to do:

data.push('rows', myNewRow);

And it will be reflected in the chart.

[vtellier]

I have been in troubles with the property binding as well. I actually did not succeed to get it to work, unless i bind to the rows property using the attribute binding rows$="[[myArray]]".
Of course doing so is kind of nasty as the array will be serialized, therefor I got problems with dates etc.

The only way I got it to work was with the dirty check.

Another was to change the google-chart element itself, and bind the observer using the wildcard path myArray.* so the array mutations are propagated as explained in the documentation:

    observers: [
      '_draw(_chart, _dataView)',
      '_subOptionChanged(options.*)',
      '_rowsOrColumnsChanged(rows.*)' // new registration of the observer
    ],

Doing so I got all my mutations reflected in the chart.

I don't know how it would behave with big amount of data, but from my perspective, it is sounds better to use the google-chart using the standard data-flow instead of forcing a dirty check.

[wesalvaro]

@vtellier The problem with watching slice changes is gonna be that not every slice change should trigger a redraw. I don't understand why you would ever need to bind to the attribute unless you're getting the property to trigger because it's re-deserializing your JSON every time at that point.

You might be able to get by with a slice on the original array. But I'm not sure what your setup looks like without a demo on which to comment. There are definitely cases which are less than ideal for the dirty checking but I do think, in general, they are better than slice watching. Especially when charts grow large or there are multiple charts on a page.