Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix pushed down chart on multi line horizontal legends #31466

Merged
merged 6 commits into from
Feb 27, 2019

Conversation

flash1293
Copy link
Contributor

@flash1293 flash1293 commented Feb 19, 2019

Summary

Fixes #15668

Fixes the issue with multi line horizontal legends which push down the chart into the x axis (see discussion in #30960)

This is fixed by rendering the visualization a second time after refreshing the legend after the first render:

if (this.vis.params.addLegend) {	
          this.$scope.refreshLegend++;	
          this.$scope.$digest();	
          this.vis.vislibVis.render(esResponse, this.vis.getUiState());
}

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

- [ ] This was checked for breaking API changes and was labeled appropriately
- [ ] This includes a feature addition or change that requires a release note and was labeled appropriately

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@flash1293 flash1293 force-pushed the 17488/fix-multiline-legend branch from 422d15d to 43e3dc6 Compare February 19, 2019 16:27
@elasticmachine
Copy link
Contributor

💚 Build Succeeded


// re-render after the legend is initialized to correctly take
// the legend height into account
this.vis.vislibVis.render(esResponse, this.vis.getUiState());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why was this working for the left/right legend ? we have the same scenario, where chart needs to take new width into account ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the left/right legend has a fixed width and is taken correctly into account even if there are no entries in the legend in the first render pass

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok ... so before the logic was

  • render the legend (so chart knows the size)
  • render the chart
  • render the legend again with correct data (which chart prepared)

now:

  • render legend
  • render chart
  • render legend with correct data
  • render chart with correct size

.... this feels a bit too much, but i agree its a working easy fix

couldn't we just:

  • render chart
  • render legend with correct data
  • render chart

(this way we get rid of one legend render)
or even better, extract the logic in chart used to produce correct legend info, or separate the chart in two parts .. prepare data and render

then:

  • chart prepare data
  • render legend (with correct data)
  • chart render

Copy link
Contributor Author

@flash1293 flash1293 Feb 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • chart prepare data
  • render legend (with correct data)
  • chart render

I tried to do this at first, but a lot of tests failed because of it. I will restore the state so we can take a look on it.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@flash1293
Copy link
Contributor Author

I don't understand why this test is failing- it works for me if I run the test locally. Any ideas @ppisljar ? If the double pass rendering isn't too bad for performance (thinking about big dashboards), I will revert to re-rendering.

@flash1293 flash1293 force-pushed the 17488/fix-multiline-legend branch from 1762080 to f83c14c Compare February 22, 2019 08:58
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@flash1293
Copy link
Contributor Author

Jenkins, test this.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@flash1293
Copy link
Contributor Author

@timroes @ppisljar could you take another look? it now does the following:

  • Prepare data for legend
  • Render legend
  • Render chart
  • Re-render legend (because of heatmap and gauge)

Heatmap and gauge do some calculations during the rendering which is required to build the legend correctly. This means the multi line bug isn't fixed for those chart types (which is an edge case IMHO because you rarely have this many legend entries in those chart types plus the labels tend to be very short).

Refactoring the control flow here to also fix heatmap and gauge would require effort which IMHO isn't worth it at the moment because we will start using elastic-charts here soon.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

this.vis.vislibVis.render(esResponse, this.vis.getUiState());

// refreshing the legend after the chart is rendered.
// this is necessary because some visualizations (heatmap and gauge)
// provide data necessary for the legend only after a render cycle.
if (this.vis.params.addLegend) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do this only for heatmap and gauge.
also, it seems that for heatmap and gauge we also need to rerender the chart again to fix top/bottom legend overflow

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do this only for heatmap and gauge

Does it make sense to make this code specific to certain chart types? If a plugin vis uses the same "hack", its legend wouldn't show up at all.

also, it seems that for heatmap and gauge we also need to rerender the chart again to fix top/bottom legend overflow

Yes, see my comment above regarding that. It's really edge-casey to trigger this bug for heatmap and gauge and I wasn't sure whether it makes sense to hurt performance for all heatmaps and gauges for this. If you think that's reasonable I will add a re render just for these chart types.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a third party plugin would want to do something similar, they would need to modify the vislib legend anyway as heatmap and gauge special legend handling is hardcoded in there.

can we try offload the decision if to rerender or not to the legend itself ?

i agree hitting the bug with heatmap or gauge is less likely, but on dashboard it might still happen quite often. And since the solution is anyway a hack, it would be nice if it actually fully fixes a problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a third party plugin would want to do something similar, they would need to modify the vislib legend anyway as heatmap and gauge special legend handling is hardcoded in there.

Ah, you are right. I moved the list of "special" visualizations to a central constant to emphasise the connection.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@flash1293 flash1293 requested a review from ppisljar February 26, 2019 09:02
Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, tested on chrome linux

@flash1293 flash1293 merged commit 295de1e into elastic:master Feb 27, 2019
@flash1293 flash1293 deleted the 17488/fix-multiline-legend branch February 27, 2019 14:30
flash1293 added a commit to flash1293/kibana that referenced this pull request Feb 27, 2019
flash1293 added a commit to flash1293/kibana that referenced this pull request Feb 27, 2019
flash1293 added a commit to flash1293/kibana that referenced this pull request Feb 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

More values in legend causing chart to break
3 participants