[Feature Request]: Splitting values into multiple inputs with teal.picks

[llrs-roche]

Feature description

Many modules have a pattern that is the selection of a variable and then some comparison of the values on it: Usually there is a control/reference group and then other groups (treatment or all the other groups):

How we implement that with picks being used to select the variable?

If we use picks for the variable selection then the UI will be different between variables and the values used for the comparison.

var = picks(dataset(...), variables(...))
control = selectInput()
treatment = selectInput()

If we internally use picks to select all of them we can end up with a similar looking UI but the user could select the same variable on control and treatment (if we don't add some validation):

var = picks(dataset(...), variables(...))
control = c(var, values(selected = 1))
treatment = c(var, values(selected = 2))

My personal opinion is that with the second approach we can create a function/widget on teal.picks that does that validation automatically. We could detect automatically what's on the control/reference group and extract it from the other choices.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[osenan]

Hi @llrs-roche I agree with the choice of the second approach.
I have several questions:

1. Should this be part of picks or from specific package? Ideally it should be teal.picks because it probably will be required in more than one package. However, I do not see an easy way to modify the module script of picks to include this functionality.
2. On the other hand, for every module package that has this situation it would be much easier to add one utility function or functions, implement control and treatment inputs with teal.picks::variables and then validate the selections with the utility functions.

[averissimo]

These are quite specific use cases and the second use case is very complex as it

# add nothing new to API
var = picks(dataset(...), variables(...))
control = utils::modifyList(var, list(values = values(selected = 1)))
treatment = utils::modifyList(var, list(values = values(selected = 2)))

# pipe function that handles it (new)
var = picks(dataset(...), variables(...), values(...) |> split_values("treatement", "control"))

# named values (new)
var = picks(dataset(...), variables(...), treatment = values(...), control = values(...))

# OR operation on values (reflect on the merge)
# we still need to allow custom labels in values
var = picks(dataset(...), variables(...), values(...) || values(...))

For this case, I think current API is just short of fixing the same dataset and variable for both.

---

For the second case is much more complex as the inputs are related and you can drag them. How would that even look?

# ?
var = picks(dataset(...), variables(...), values(...) |> disjoint_select("ref", "comp", none = TRUE))

[llrs-roche]

I have several questions:

1. Should this be part of picks or from specific package? Ideally it should be teal.picks because it probably will be required in more than one package. However, I do not see an easy way to modify the module script of picks to include this functionality.

I too think this should be on teal.picks or teal.widgets, I wouldn't modify the default UI of selection but create a new one.
picks(), datasets(), variables() and values() are not tied to picks_ui functions.

2. On the other hand, for every module package that has this situation it would be much easier to add one utility function or functions, implement control and treatment inputs with teal.picks::variables and then validate the selections with the utility functions.

As André points out there are some extra validation/process that aren't as easy to make with a "simple" utility function.

---

For the first one I like this approach:

# add nothing new to API
var = picks(dataset(...), variables(...))
control = utils::modifyList(var, list(values = values(selected = 1)))
treatment = utils::modifyList(var, list(values = values(selected = 2)))

However, with picks we will need to validate that both control and treatment have the same dataset and variable selected (or mark them as "immutable").

---

The second case I think is where a new widget is really necessary.

picks(), datasets(), variables() and values() can return the values available and then it would be a matter of JS and some html to arrange on the three boxes for group, reference and comparison. We might need to check more in detail the transformation and handling of this case in order to properly implement it.

---

Edit: I was working on a module where the module itself has to implement the UI for this kind of selection. I don't think this is a good approach as we can end up having to maintain multiple variants of selections like these.

[llrs-roche]

For the first one I like this approach:

# add nothing new to API
var = picks(dataset(...), variables(...))
control = utils::modifyList(var, list(values = values(selected = 1)))
treatment = utils::modifyList(var, list(values = values(selected = 2)))

However, with picks we will need to validate that both control and treatment have the same dataset and variable selected (or mark them as "immutable").

Just for reference, this doesn't work as values() has an assertions that selected of class numeric must be of length 2: checkmate::check_numeric(selected, len = 2, sorted = TRUE, finite = TRUE).

[averissimo]

There's a way to do it with current API, it's not ugly, but it's not pretty

# teal.picks#14
pkgload::load_all(".../teal.picks")

values_index_fn <- function(ix) {
  rlang::new_function(
    args = rlang::pairlist2(x = ),
    body = rlang::expr("i" %in% ls(.env <- parent.frame()) && .env$i %in% !!ix),
    env = rlang::base_env()
  )
}

ab <- iris |> dplyr::mutate(special = rep(c("a", "3", "4"), 50)) |> tibble::as_tibble()
aa <- picks(
  datasets("iris", "iris"), 
  variables("special", "special"), 
  values(
    c("a", "3", "4"), 
    selected = values_index_fn(c(1, 2))
  )
)
teal.picks::resolver(x = aa, data = teal.data::teal_data(iris = ab))
#> <picks>
#>   <datasets>:
#>     choices: iris
#>     selected: iris
#>     multiple=FALSE, ordered=FALSE, fixed=TRUE
#>   <variables>:
#>     choices: special
#>     selected: special
#>     multiple=FALSE, ordered=FALSE, fixed=TRUE, allow-clear=FALSE
#>   <values>:
#>     choices: a, 3, 4
#>     selected: a, 3
#>     multiple=TRUE, ordered=FALSE, fixed=FALSE

[llrs-roche]

I was experimenting with using helper as described on the previous comment:
0) This approach is evaluating the index or a very precise location of the resolver. It doesn't lead to generalizations or simplifications of the many code branches.

1. we do our own data-masking on teal.picks: I think there is room for improvement here with rlang even though I wasn't able to find a way to use it nicely with rlang. It fails on

   aa2 <- picks(
     datasets("iris", "iris"), 
     variables("special", "special"), 
     values(
       c("a", "3", "4"), 
       selected = index(c(TRUE, FALSE, TRUE))
     )
   ))
   teal.picks::resolver(x = aa2, data = teal.data::teal_data(iris = ab))
   ##  <picks>
   ##     ...
   ##    <values>:
   ##     choices: a, 3, 4
   ##     selected: a
   ##     multiple=TRUE, ordered=FALSE, fixed=FALSE

2. If we use functions helpers we still need to figure out how to display the right UI for each picks. Two selected values could be index, values or range, we still need to use a class or some attribute to figure it out. With arguments on the values() constructor we get it for free.