slider snaps from edge in RangedFilterState
#189
Conversation
|
Use this app to test (thanks @nikolas-burkoff): |
There was a problem hiding this comment.
As we're going into main we should have NEWS? We may need a test or two?
Also merge into refactor branch
Could there be a problem in teal that app developers have specified a specific filter i.e. (list(ADSL = list(x = selected(0.0009, 1)) and that gets automatically rounded for users?
Add actionButton("set_filter", "Set filter state to [0.0091, 1]") into the test app UI and observeEvent(input$set_filter, my_filter_state$set_selected(c(0.0091, 1))) into its server function
I wouldn't spend too much time on this though as we're moving to allow users to enter a range and not just pick from a slider and at that point we can handle this fully. Please add your thoughts about this (and the complexities of jumping between slider and range here)
| }, | ||
| error = function(error) stop("The array of set values must contain values coercible to numeric.") | ||
| ) | ||
| values <- as.numeric(values) |
There was a problem hiding this comment.
do we need a suppresswarnings here?
There was a problem hiding this comment.
In the previous version these warnings were never actually triggered.
They could be suppressed or they could be logged, depending on how we want to report the set range.
Works just as well with these modifications, |
There was a problem hiding this comment.
Looks good, I'd go further without a need to calculate pretty_choices twice in the initialize and ui_inputs.
teal.widgets::optionalSliderInput(
inputId = ns("selection"),
label = NULL,
min = private$choices[1],
max = private$choices[2],
value = private$choices,
step = private$step or private$choices$step
width = "100%"
)
- Reason why I requested selected and choices to be identical in initialize:
Please be aware of the methodis_any_filteredwhich checks if the choices and selected are the same. If they identical it means that fata doesn't have to be filtered so condition is not returned.
is_any_filtered = function() {
if (!setequal(self$get_selected(), private$choices)) {
TRUE
} else if (!isTRUE(self$get_keep_inf()) && private$inf_count > 0) {
TRUE
} else if (!isTRUE(self$get_keep_na()) && private$na_count > 0) {
TRUE
} else {
FALSE
}
},
|
Unfortunately, the |
|
See here for how Nik's button problem is "solved". This means the subsetting call need not contain the exact values passed to the filter API. E.g. one may wish to filter on this: but the variable in question is: thus the prettified range is: and so the cal will be |
Unit Test Performance Difference
Additional test case details
Results for commit bb9a1ea ♻️ This comment has been updated with latest results. |
|
Code Coverage SummaryDiff against mainResults for commit: bb9a1ea Minimum allowed coverage is ♻️ This comment has been updated with latest results |
Merging `main` branch into `filter_panel_refactor` following #189. --------- Co-authored-by: chlebowa <chlebowa@users.noreply.github.com> Co-authored-by: Dawid Kałędkowski <dawid.kaledkowski@gmail.com>
Solves #184.
Range of numeric variable is prettified first, before anything is created.
Slider is created based on prettified range (as previously).
Initial selection is set based on prettified range (previously on actual range).
Condition call is based on prettified range (previously on actual range).
Formatted output is based on actual range and values (as previously).