Skip to content

Create custom labels for values#47

Open
michaelcurry1123 wants to merge 10 commits intoerblast:masterfrom
michaelcurry1123:master
Open

Create custom labels for values#47
michaelcurry1123 wants to merge 10 commits intoerblast:masterfrom
michaelcurry1123:master

Conversation

@michaelcurry1123
Copy link
Copy Markdown

Hi @erblast!

@bcjaeger and I worked on creating a custom label for each value bar. This allows used to add N or % to each value within stratum. I know you previously mentioned you would be open to other people contributing to the package and wanted to pass this along to you.

Best,
Mike and Byron

@erblast
Copy link
Copy Markdown
Owner

erblast commented Apr 22, 2026

Dear Mike and Byron,

thank you for this contribution this is a cool feature. I would have a couple of requests though before I can merge this.

  • fix Undocumented arguments in Rd file 'alluvial_long.Rd' ‘custom_value’
  • rename the new parameter from custom_value to custom_label (I think this is more precise)
  • add examples to alluvial_wide and alluvial_long within the \dontrun{} roxygen tag that showcase the new parameter
  • add unit test testing the the new parameter for each function
  • easyalluvial:::pretty_num() and easyalluvial:::pretty_num_vec() in alluvial_model_response.R already have some logic for rounding numerical values for labels. Please update these function instead of introducing the new table.glue dependency. This also creates less work when updating table.glue for you do not have to run reverse dependency checks.
  • we are getting NOTES on unbound global variables which are usually caused by unquoted dplyr column names. using rlang::.data$ is the currently preferred approach or to use string vectors in dplyr functions that support tidyselect. When easyalluvial was released it was still common to add them to utils::globalVariables, there is a call at the top of alluvial_wide.R you can add those here for example or use rlang.data[["column name"]] if you want.
  • easyalluvial uses snapshots to control that the plots are consistent. This is a pixel perfect approach. These snapshots can also change with new R or ggplot2 releases. Theoretically the new parameter that you introduced should not change the existing snapshots. Please check this locally, using testthat::snapshot_review() after running devtools::test(). However do not update the files in tests/testthat/snaps. If this needs updating because the R version ggplot2 has changed I will need to update this before you can merge.
  • finally run devtools::check() and take care of all Warnings, Notes and Errors except for these snapshot errors that I might have to deal with.

Sorry for this longish list of requests. Happy to work on this, I will try to reply and give you feedback within a few days after you update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants