Issue with display of labels with new Bar chart

[sqja]

Hello,

Previously with legacy bar chart widget (which is now deprecated), we can see a label under every bar.

With new bar chart widget (with Superset v3.0.1 version), it seems there is no possibility to obtain the same result with a label for every bar, only one bar out of two gets a label.

The field in X axis is a String, with legacy bar chart it was used in mandatory 'Dimensions' section of the configuration, with the new bar chart it is used in the mandatory 'x-axis' section of the configuration.

Could you please advise if there is a way to attain the same result with new bar chart widget or if it is a regression ?

Best regards

[sfirke]

I noticed this too as a change from 3.0.0 to 3.1.0rc1. In my case it's a line chart and I'm supplying a numeric x-axis. Here's the chart in 3.0.0:

Same chart in 3.1.0rc1:

Chart config:

[michael-s-molina]

@villebro I assigned this issue to you as I think you worked on a feature that might be related.

[villebro]

@sqja this is intentional, and is to ensure the labels don't overlap. To force the labels to render, you can switch the rotation from 0 degrees to 45 degrees. See an example below with lots of categories:

@sfirke I believe the behavior you're seeing is expected behavior - when the x-axis is numeric or temporal, it will dynamically calculate where to place the ticks/labels. To get the previous behavior (which was in fact a regression from 2.x to 3.0, IIRC), you can cast the numeric x-axis to a string, after which it should render correctly. As a follow-up, we may want to add a control for forcing numerical (or even temporal) x-axes to categorical ones to avoid having to cast to VARCHAR or other categorical type. Thoughts @sfirke @michael-s-molina ?

[michael-s-molina]

To get the previous behavior (which was in fact a regression from 2.x to 3.0, IIRC), you can cast the numeric x-axis to a string, after which it should render correctly.

This might be a solution given that I didn't see a viable alternative using ECharts. One small change we can do is to add the 90° rotation to the rotation control. Right now it only contains 0° and 45° and even though you can manually enter 90°, it would help given that that's what you'll probably need if you have a large dataset.

Keep in mind that by converting temporal and numeric values to categories you will have the same problem outlined by #26034. So it's a trade-off that users need to evaluate but at least we give them the option.

As a follow-up, we may want to add a control for forcing numerical (or even temporal) x-axes to categorical ones to avoid having to cast to VARCHAR or other categorical type.

I think having this control is important because manually forcing the conversion will be a painful experience. The y axis may also have a control or we can design the control in such a way that it affects both axes.

[villebro]

FYI, I believe we used to have a 90 degree option, but it was removed for some reason. I forget what it was, but I also propose adding it back.

[michael-s-molina]

I added a PR to reinstate the 90° option. We also discussed during the PR reviews meeting and agreed that users should be responsible for converting time and numerical columns to categories. Adding a control for that seems a bit overkill given that we may have other types of conversions needed when creating the perfect visualization but we don't offer controls for each of them.

I'll close the issue with the guideline to manually convert columns and use label rotation to resolve the problem.

[sfirke]

I'm satisfied with that resolution, thanks for the discussion and restoring the 90 degree rotation.

Can we add this to the release notes, as it will be a change that some users may notice and wish to undo? Even if it's not breaking since it's fixing a regression. Maybe we link back to this issue.

[michael-s-molina]

Can we add this to the release notes, as it will be a change that some users may notice and wish to undo? Even if it's not breaking since it's fixing a regression. Maybe we link back to this issue.

#26208