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
Fix sporadic dates (#3664) #3665
base: main
Are you sure you want to change the base?
Conversation
This prevents spurious updates while typing, but still sends when enter is pressed, focus is lost, or the GUI is clicked (due to the remaining `changeDate` and `change` handlers).
|
...nope, looks like even with updated roxygen, devtools::check() still doesn't update package.json; I need to manually run |
@wch whether or not y'all accept this PR you should probably update the package.json version number on main |
Conflicts: NEWS.md inst/www/shared/shiny.js inst/www/shared/shiny.js.map inst/www/shared/shiny.min.js inst/www/shared/shiny.min.js.map
This will probably fail the R 3.5 test for the same reason as #3683 (comment) and main |
It looks like some other checks also failed due to R 4.2.3 being released today but not quite making it to the expected repositories yet |
Is there a way to rerun the tests here? Edit: Never mind, looks like the merge of main did it. |
This pull request removes the handlers for
keyup
andinput
fromdateInput
anddateRangeInput
. This prevents spurious updates while typing, but still sends the parser's best interpretation of the field when enter is pressed, focus is lost (i.e. the user clicks out), or a date selection is made in the GUI (due to the remainingchangeDate
andchange
handlers).A value of
null
(fordateInput
) orNA
(fordateRangeInput
) is still sent immediately when the field is cleared, but this can be more easily checked for and ignored on the server side. I suspect thatbootstrap-datepicker
is interpreting the empty string as a special value and firing off thechangeDate
event, and stopping that would probably be much more intensive than commenting out a few lines of code.This therefore mostly fixes #3664 .
Not sure if y'all will want to shove this into 1.7.2, leave it for the next release, or if there's some crazy use case I can't imagine where you'd want "2001-01-0" to be immediately interpreted as the last day of 1999.Edit: Merged in 1.7.2-1.7.4 changes, no conflicts except for minified JS as usual