legendrank scrambled by fillcolor with type='scatter'
Nobody has claimed this yet.
- Dominant language
- R
- Stars
- 2.7k
- Forks
- 641
- PR merge metrics
- No merged PRs in 30d
Description
Expected behavior
When making a stacked area chart, the ordering of the legend values follows the ordering of the legendrank argument.
Actual behavior
When making a stacked area chart, the ordering of the legend values depends on the legendrank argument in combination with the alphabetical ordering of the fillcolor argument. Somehow the fillcolors seem to be scrambling the order.
Here's an example:
# The goal is to make a stacked area chart, where each fill color is a severity
# level. Then, the legend should be ordered by severity
library(plotly)
severities = c('Mild', 'Moderate', 'Severe')
severity_colors = c('#FF0000', '#440000', '#AA0000')
# ^ colors chosen specifically to be out of alphabetical order
severity_color_dict = setNames(severity_colors, severities)
timeline = data.frame(Time = rep(1:15, 3),
coverage = rep(1, 45),
Severity = factor(rep(severities, each = 15)))
timeline$fill = severity_color_dict[timeline$Severity]
# default order
plot_ly(timeline, x = ~Time, y = ~coverage, name = ~Severity, type = 'scatter',
mode = 'none', stackgroup = 'one', groupnorm = '')
# add fillcolor-- now the legend is in alphabetical order of fillcolor
plot_ly(timeline, x = ~Time, y = ~coverage, name = ~Severity, type = 'scatter',
mode = 'none', stackgroup = 'one', groupnorm = '', fillcolor = ~fill)
# this should be ordered by Severity, but it's still in alphabetical order of
# fillcolor
plot_ly(timeline, x = ~Time, y = ~coverage, name = ~Severity, type = 'scatter',
mode = 'none', stackgroup = 'one', groupnorm = '', fillcolor = ~fill,
legendrank = ~as.integer(Severity))
# The intended order can only be acheived by using the alphabetical ordering of
# the fill colors to "unscramble" the legendrank
unscramble_dict = order(severity_colors)
plot_ly(timeline, x = ~Time, y = ~coverage, name = ~Severity, type = 'scatter',
mode = 'none', stackgroup = 'one', groupnorm = '', fillcolor = ~fill,
legendrank = ~unscramble_dict[as.integer(Severity)])
Session info
R version 4.1.2 (2021-11-01)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.2 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
[6] LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] plotly_4.10.2 ggplot2_3.4.2
loaded via a namespace (and not attached):
[1] magrittr_2.0.3 tidyselect_1.2.0 munsell_0.5.0 viridisLite_0.4.2 colorspace_2.1-0 R6_2.5.1 rlang_1.1.1
[8] fastmap_1.1.1 fansi_1.0.4 httr_1.4.6 dplyr_1.1.2 tools_4.1.2 parallel_4.1.2 grid_4.1.2
[15] data.table_1.14.8 gtable_0.3.3 utf8_1.2.3 cli_3.6.1 withr_2.5.0 ellipsis_0.3.2 crosstalk_1.2.0
[22] htmltools_0.5.5 yaml_2.3.7 lazyeval_0.2.2 digest_0.6.31 tibble_3.2.1 lifecycle_1.0.3 tidyr_1.3.0
[29] purrr_1.0.1 htmlwidgets_1.6.2 vctrs_0.6.2 glue_1.6.2 compiler_4.1.2 pillar_1.9.0 generics_0.1.3
[36] scales_1.2.1 jsonlite_1.8.5 pkgconfig_2.0.3
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 by running the reproducible R examples using plot_ly with type='scatter', stackgroup, fillcolor, and legendrank. Trace how stacked-area legend ordering responds to those arguments; done means legend order follows legendrank consistently, regardless of fillcolor ordering, while preserving the reported 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
- 35/100