Review
Overall, I think the package is well written, very well documented, and offers a sufficiently complete set of convenience functions that can adequately meet the needs of some researchers who are relatively unfamiliar with R. You may find my review checklist here.
Major Points
1. Dependency issues
As this package wraps convenience functions around existing packages, solid dependency handling is key.
Both at the point of installation and when certain functions are called, I encountered numerous namespace errors. I think the main issue is that this package relies on certain (newer) versions of depencency packages, but package functions only check whether the package is installed or not. I would recommend adding the minimum package requirement in the version
argument in calls to rlang::check_installed()
.
Example of what happens if you try to use a function where a dependency is not installed at all:
> nice_table(t.tests)
ℹ The package "flextable" is required for this function.
✖ Would you like to install it?
1: Yes
2: No
Example of what happens if you try to use a function where a dependency is installed, but a newer version is required:
> moderations <- nice_mod(
+ data = mtcars,
+ response = c("mpg", "disp"),
+ predictor = "gear",
+ moderator = "wt"
+ )
Error: 'r2_semipartial' is not an exported object from 'namespace:effectsize'
The above was solved by updating the effectsize
package with install.packages("effectsize")
.
This issue therefore affects two points in the checklist:
i. Functionality/Installation
Installation via install.packages("rempsyc")
resolves without issue, but calling library(rempsyc)
throws error:
Error: package or namespace load failed for ‘rempsyc’: object ‘pick’ is not exported by 'namespace:dplyr'
Once I updated dplyr
from 1.0.9 to 1.1.2, then package loaded correctly. Thus, minimum version as stated on CRAN should be updated.
ii. Documentation/Installation instructions
Dependencies and required versions are not stated on the main documentation page, though they are stated on CRAN. I'm not sure what is considered best practice for loading depencies, but the author may consider including a step for the manual installation of all depencies or inserting a chunk for installing dependencies in the "Getting Started" section of each tutorial. rlang dependecy checks could then be kept as a backup. Indeed, it feels a bit hacky to interrupt workflow for installing a dependency.
2. Tests missing
i. Documentation/Automated tests
testthat only available for nice_violin()
currently. Should be implemented for all functions (?).
Minor Points & Suggestions
-
The tutorial for the nice_mod()
may benefit from a little bit more explanation or perhaps link to a couple resources for setting up a moderation/simple slopes analysis. It may be obvious, but I would also suggest explicitly mentioning that these functions compute straight linear models under the hood.
-
It may be useful to add an argument that would allow a user to get row indices from extract_duplicates()
and best_duplicate()
that would make data wrangling easier.
-
I would suggest including a chunk in the tutorial for nice_randomization()
encouraging users to set (for reproducibility) or randomize the seed before running the function.
-
Users may wish to use the venn diagram visualization for applications other than IOS. Thus, it might be useful if the maximum overlap for overlap_circle()
could go up to 100% (it currently only goes up to 85%). Relatedly, as some users may wish to use the venn diagram with inputs other than (I presume) the 1-7 IOS scale, you may consider allowing users to directly define the percent overlap (e.g. 57%) and/or provide the values in each section explicitly (e.g. c(10,27,10)). Admittedly, this may make the function deviate from its intended purpose, and for such uses users could directly use functions from other packages.
-
Print color on warning messages (e.g. output from nice_t_test()
) is uses the function message_white()
which is very difficult to read on the default white background of R. I would suggest changing to the default message function.
-
It is a bit unclear to me how (or whether) nice_contrasts()
can handle nested comparisons for marginal means. In the syntax of emmeans, it is straightforward to define whether you want to know contrasts for levels of var1 within var2, and vice versa.