Closed kartikeyakirar closed 8 months ago
Changing the default value over here to this should fix this:
value = unique_entries < .unique_records_default_as_factor
However, based on the previous if
statement. I believe that the actual feature was something different:
Feature: By default if there are < 6 distinct values it should be converted into a factor. However, if the user decides to keep the checkbox on/off for a given column, it should remain the same and not change.
☝🏽 That behaviour is broken if we just make the default selection as per our logic.
The crux of the problem is that we use the same checkbox input for every column selection.
Feature: By default if there are < 6 distinct values it should be converted into a factor. However, if the user decides to keep the checkbox on/off for a given column, it should remain the same and not change.
So here are two options
Simple Fix: Update the checkbox every time a user selects a row from the DT table. This will check the condition unique_entries < .unique_records_default_as_factor
and update the checkbox accordingly.
Complex Approach: Implement a mechanism to store information about user selections on the checkbox for each column. If a user makes any changes after the default selection, the mechanism should retain that selection.
What happened?
The dynamic behavior of the checkbox is not working as intended. The checkbox should be checked or unchecked based on the condition
unique_entries < 6
. However, it seems that the issue is caused by the conditionis.null(isolate(input$numeric_as_factor))
always being evaluated as FALSE after the initial assignment.Check
mtcars$cyl (<6)
andmtcars$hp (<30)
sample code
sessionInfo()
No response
Relevant log output
No response
Code of Conduct
Contribution Guidelines
Security Policy