ParameterChanged event creates race condition

[jhegele]

This is a bit of a quirky bug that I've run into a couple of times now. If I have a dashboard that requires time to recalculate the view layout after a parameter change, a race condition is created between the ParameterChanged event firing and the data completing its update. When a parameter is changed, it looks like the event fires immediately which causes issues if you are subsequently using getSummaryData(). Here's an example:

When I update the parameter (at the bottom of the viz), it updates the bar chart to contain nine orange bars. However, my extension is pulling summary data from a much more complex sheet where the view takes longer to render. So, the extension is getting "old" summary data that indicates that only four bars are orange because the ParameterChanged event is firing before the data is actually updated. After I manually reload the extension, it shows the correct value since all of the views have updated and rendered.

For my general use case, this issue is likely solvable via issue #167. But wanted to add a dedicated issue for this item as there may be more nuanced use cases as well.

[jhegele]

Quick follow-up as I'm seeing the same thing on MarkSelection events. I suspect that anytime you set an event listener and subsequently want to pull data, there is a risk of this race condition occurring.

[LGraber]

Thanks John. I will open an item on this as the behavior here should be more predictable, regardless of whether we have a summaryDataChangedEvent (which is not in the immediate plans).

[LGraber]

As an update John ... can you confirm that you are only seeing this on desktop? We are actively working on a fix for this that should address this issue on desktop. This should not occur on server.

[LGraber]

This should have been resolved in 2019.1. Please let us know if you are still seeing this. This only occurred if the underlying db query was not fast enough and we ended up popping up a progress dialog.