parameters with choices and multiple use a select

[aronatkins]

a small number of choices does not force radio buttons.

A document defined like:

---
title: selects
params:
    multifewchoices:
        multiple: true
        choices: ["boston","springfield","worcester"]
        value: "boston"
---

Running rmarkdown::knit_params_ask("inputs.Rmd") presents the UI:

This previously required an explicit input declaration:

---
title: selects
params:
    multifewchoices:
        input: multiple
        multiple: true
        choices: ["boston","springfield","worcester"]
        value: "boston"
---

With this change, the input is unnecessary.

[yihui]

Thanks!

[yihui]

Users probably have no idea what this short sentence means.

Suggested change

	- A parameter allowing multiple selections uses a select input control by default regardless of the number of choices.
	- Added an option `multiple` for parameters with `choices` to use the `select` or `radio` input control regardless of the number of choices. Previously, the `select` input is used when the number of choices is greater than 4, otherwise the `radio` input is used. Now `select` will be used when `multiple` is true, and `radio` is used when `multiple` is false, e.g.,
	---
	params:
	foo:
	choices: ["a", "b", "c"]
	multiple: true # use select input
	bar:
	choices: ["a", "b", "c", "d", "e"]
	multiple: false # use radio input
	---
	```

[aronatkins]

We have long supported "multiple". Previously, we made the wrong choice when there were a small number of choices and multiple were allowed.

This is the one test case that demonstrates the change:

  expect_equal(params_get_input(list(
    value = "red",
    multiple = TRUE,
    choices = c("red", "green", "blue")
  )), "select")

Previously, the small number of choices causes us to inferred a "radio" input without recognizing the multiple = TRUE constraint.

I've pushed a NEWS update, but it feels too wordy for such a small, subtle change. I defer to your judgement.

[yihui]

Oh I see. Thanks for the explanation! I have totally forgotten the multiple option.

[aronatkins]

(force-pushed after rebasing from main and resolving NEWS.md conflicts)

[yihui]

For the case of length(choices) > 4 and multiple = FALSE, we should use radio, right?

Suggested change

	## select for a large number of choices and multiple choices.
	if (isTRUE(param$multiple)) {
	input <- "select"
	} else if (length(param$choices) > 4) {
	input <- "select"
	} else {
	input <- "radio"
	## select for a large number of choices if multiple is not specified
	if (is.null(param$multiple))
	param$multiple <- length(param$choices) > 4)
	input <- if (param$multiple) "select" else "radio"

[aronatkins]

No, I think we want to continue to use select when there are many choices. Consider a list naming all of the countries in the world. A set of radio buttons would consume way too much real estate.

Radio buttons are reserved for small numbers of choices when you only want to choose one. Using four items as the tipping point felt about right when we were first working on this. Radio buttons work when you've got a "handful" but not more. It's totally subjective, though, and someone can always override that heuristic by declaring input: radio or input: select in their document.

[aronatkins]

Also: Your suggestion is setting param$multiple when it is not user-specified. That changes the behavior of select and turns it from a single-selector to a multi-selector.

Many of the parameter fields become arguments to the Shiny UI controls. In this case, we pass multiple to shiny::selectInput().

https://rstudio.github.io/shiny/reference/selectInput.html

[aronatkins]

That last comment probably doesn't apply since the value for param$multiple does not escape this function.

Sorry for the repeated replies on this one... Your comment and code might be inconsistent. We never want to use radio for a large number of inputs. I think your code accomplishes that, but your PR comment (not the code comment) says otherwise.

At any rate -- I think the tests capture the scenarios accurately. If you think your rewrite is worth it, fine. I worry that setting param$multiple like you have is going to confuse the "future us" because we are giving it a TRUE value even when the parameter does not want to allow multiple choices.

[yihui]

I see what you mean now. Thanks again for the explanation!