ggplotly() is unable to merge legend entries across layers
Nobody has claimed this yet.
- Dominant language
- R
- Stars
- 2.7k
- Forks
- 641
- PR merge metrics
- No merged PRs in 30d
Description
Thanks for an amazing package! The mapping between plotly and ggplot is particularly impressive and very powerful!
However, ggplotly fails to reproduce the appropriate legends generated by ggplot in non-trivial facet_wrap cases. After discussion on stackoverflow some of this behavior appears to be a bug.
Consider the following minimal reprex:
library(plotly)
library(ggplot2)
p <- mpg %>%
ggplot(aes(year)) +
geom_ribbon(aes(ymin=cty, ymax=hwy, fill = manufacturer), alpha=0.2) +
geom_line(aes(y = hwy, col=manufacturer)) +
facet_wrap(~class)
p
plotly::ggplotly(p)
Note that (a) we get too many plotly legend entries, duplicating the legend for each facet, due to legendgroup not being correctly handled. Also note (b) the legends we do and don't get depend on the order (do we do geom_ribbon first or geom_line first). The bug does not appear if we have only one geom, and the missing legends continue as we add more geoms.
Perhaps not related -- but the interactive zoom options in faceted plots are not entirely intuitive either, i.e. it's not possible to zoom the whole window on a single facet plot. (Perhaps the take home is that it might be better to render facet plots as more independent objects in plotly)?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the minimal ggplotly() reprex using geom_ribbon, geom_line, and facet_wrap(~class), then inspect how legendgroup is handled across layers and facets. Compare the converted legends with ggplot2's expected legends; done means no duplicate or missing entries regardless of geom order, while preserving facet behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- data-visualization
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100