Visualizations are instantiated twice when changing options

[thomasneirynck]

Changes in the options-tab trigger a refresh of the visualization. This refresh occurs twice for a single change.

This is an internal performance issue and not noticeable to the user.

To reproduce:

1. in a debugger, set a breakpoint inside the constructor of a visualization
2. make a change in the options tab
   -> notice that you hit the breakpoint twice. Between the first and second time, you'll see the correct visualization flash on the screen. It gets replaced by the second update.

[thomasneirynck]

This will likely impact #7899 and vice versa.

[thomasneirynck]

The visualization is refreshed twice, using a separate mechanism each time

1. the visualization just rerenders
2. a full round trip to ES is performed. When the response comes back, the visualization refreshes again.

(2) is not necessary. When changing the options, the correct data is already loaded in memory. No new fetch of ES is required.

[thomasneirynck]

There are 2 listener mechanisms, both concurrently active:

(1) The main visualization component (ui/public/visualize/visualize.js) listens to any changes in the vis.params. These are parameters that are configured in the form panels. (Cf. $scope.$watchCollection('vis.params'......)

A change there triggers a refresh of the visualization. It does NOT trigger a refresh when the vislib params remain unchanged. The latter are a subset of all vislib params and describe properties of the visualization only (and not properties that cause a query-change). These are found in the Options-tab.

(2) The editor component (editor.js) triggers a recreation of the visualization, once the "play"-button is pressed. This causes a new query to ES (using courier). Once that query returns, the visualization is refreshed as expected. (cf. function transferVisState....)

---

Compare following flows:

a) change in Data tab: (correct)
-> both listeners trigger. (1) filters out the refresh of the visualization because there is no change in the visualization options. (2) performs a query, and when the result comes back, the visualization is replaced.

b) change in Options tab: (incorrect)
-> both listeners trigger. (1) passes, because this is an option-tab change. The visualization updates correctly. (2) performs a query, and when the result comes back, the visualization (which was already correct) is replaced once more.

---

In case of (b), the round trip registered with listener (2) should not happen.

[thomasneirynck]

@epixa @spalger I heard through the grapevine you may have some deeper knowledge off this. Can you take a look at the description of the bug before, and confirm/add feedback?

@cjcenizal I think the above is the root-cause of the issue. If we clean this up, this would benefit #7899 as well.

[thomasneirynck]

closed by #7960.