insightsengineering / insightsengineering/teal.picks
[Discussion]: Support multiple choices/select specs based on dataset
- Dominant language
- R
- Stars
- 4
- Forks
- 0
- Avg merge
- 6d 11h
- Merged PRs (30d)
- 3
Description
### Feature description
Goal: allow to support different variables/values choices/select based on the dataset being used
This is a feature that existed on `teal.transform`, but hasn't been matched by `teal.picks`
The previous API used a list of `data_extract_spec** to provide with each dataset specification and that may not be the best approach for picks.
### Proposal do discuss
- Picks specification as it is right now provides with defaults/fallback `variables`/`values`
- Dataset specific:
1. Named dataset arguments provide with dataset-specific `variables`/`values`
2. Post-picks operations to provide dataset-specific
Mock example exploring all possible options:
- Has 3 datasets
- `ADTTE` does not have a custom specification and only uses `variables()`
- `ADSL` selects `SEX` variables and has `values()`
- `ADRS` selects `AGE` variable and does not have `values()`
My concern with first approach below is that we would have repetitive parameters names.
It's is possible, but a concern nonetheless (click here to expand)
```r
foo <- function(...) {
dots <- rlang::list2(...)
datasets = Filter(function(x) inherits(x, "datasets"), dots)
variables = Filter(function(x) inherits(x, "variables"), dots)
values = Filter(function(x) inherits(x, "values"), dots)
print("Datasets")
print(datasets)
print("Variables")
print(variables)
print("Values")
print(values)
}
foo(datasets(), variables(), ADSL = variables(), ADSL = values())
#> [1] "Datasets"
#> [[1]]
#>
#> choices: tidyselect::everything()
#> selected: 1L
#> multiple=FALSE, ordered=FALSE, fixed=FALSE
#>
#> [1] "Variables"
#> [[1]]
#>
#> choices: tidyselect::everything()
#> selected: 1L
#> multiple=FALSE, ordered=FALSE, fixed=FALSE, allow-clear=FALSE
#>
#> $ADSL
#>
#> choices: tidyselect::everything()
#> selected: 1L
#> multiple=FALSE, ordered=FALSE, fixed=FALSE, allow-clear=FALSE
#>
#> [1] "Values"
#> $ADSL
#>
#> choices:
#> selected:
#> multiple=TRUE, ordered=FALSE, fixed=FALSE
```
```r
picks(
datasets(c("ADSL", "ADRS", "ADTTE")),
variables(),
ADSL = variables(selected = c(SEX)),
ADRS = variables(selected = c(AGE)),
ADSL = values(selected = "F")
```
This seems much more R-like _(functions names TBD)_
```r
picks(
datasets(c("ADSL", "ADRS")),
variables()
) |> picks_extra_variables(
ADSL = variables(selected = c(SEX)),
ADRS = variables(selected = c(AGE))
) |> picks_extra_values(
ADSL = values(selected = "F")
)
```
### Previous API
```r
variables = list(
teal.transform::data_extract_spec(
dataname = "ADSL",
select = teal.transform::select_spec(
label = "Select variables:",
choices = teal.transform::variable_choices(data[["ADSL"]]),
selected = c("AGE", "RACE", "SEX"),
multiple = TRUE,
ordered = TRUE,
fixed = FALSE
)
),
teal.transform::data_extract_spec(
dataname = "ADRS",
filter = teal.transform::filter_spec(
label = "Select endpoints:",
vars = c("PARAMCD", "AVISIT"),
choices = teal.transform::value_choices(data[["ADRS"]], c("PARAMCD", "AVISIT"), c("PARAM", "AVISIT")),
selected = "INVET - END OF INDUCTION",
multiple = TRUE
),
select = teal.transform::select_spec(
label = "Select variables:",
choices = teal.transform::variable_choices(data[["ADRS"]]),
selected = c("AGE", "AVAL", "ADY"),
multiple = TRUE,
ordered = TRUE,
fixed = FALSE
)
)
)
```
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct.
### Contribution Guidelines
- [x] I agree to follow this project's Contribution Guidelines.
### Security Policy
- [x] I agree to follow this project's Security Policy.
Contributor guide
Research direction
The issue names no files or tests. Start by reviewing the current teal.picks picks specification and the previous teal.transform data_extract_spec API, then compare the two proposed dataset-specific designs; done means an agreed implementation direction for dataset-specific variables and values choices.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100