Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic Inputs #163

Open
coatless opened this issue Mar 8, 2024 · 0 comments
Open

Dynamic Inputs #163

coatless opened this issue Mar 8, 2024 · 0 comments
Labels
p: low Address issue when time permits t: feature-request Request the addition of a new feature
Milestone

Comments

@coatless
Copy link
Owner

coatless commented Mar 8, 2024

With dynamic inputs, we aim to simplify how code inside a code cell can be executed and automatically update its result. The result is a series of input fields that sit above the code cell or can be relocated elsewhere (?) on the page.

For instance, let's take the following simulation demo:

x <- rnorm(n, 5, 3)
hist(x)

We would expect to see a normal distribution centered at 5 with an SD of 3.

The variable n is omitted from the code but controls how many observations should be generated.

So, if we wanted a slider on the cell variables, we would use inside the cell:

n <- 50 # @param {type:"slider", min:1, max:100, step:1}

For an example of:

x <- rnorm(n, 5, 3)
hist(x)

This ties the input / result change scope to the single interactive code area.

Alternatively, we could consider a shortcode outside of the cell:

{{< slider variable="n" cell-label="my-cell" min=1 max=100 step=1 value=50 >}}

As a result, we would get a document like so:

quarto-webr-demo-dynamic-input-control-widgets

This was inspired by some of the fun observable toggles Bob Rudis demoed on mastodon.

Design questions:

  1. Does it make sense to include this as a feature within the extension?
    • Is it better served if this is an option in a separate extension?
  2. Unlike with Shiny, the toggle control is highly responsive as values are updated. Should there be a delay added to avoid small step-wise changes?
  3. What kinds of input should be allowed?
    • String input, Number input, Slider input, Drop down input?
  4. Should the scope of variables be considered so that all cells involving a variable (e.g. n) be updated?
    • This would require a deep dive into reactive programming at the benefit of not worrying about outdated results on later portions of the page.
@coatless coatless added t: feature-request Request the addition of a new feature p: low Address issue when time permits labels Mar 8, 2024
@coatless coatless added this to the Future milestone Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p: low Address issue when time permits t: feature-request Request the addition of a new feature
Projects
None yet
Development

No branches or pull requests

1 participant