* selectInput/selectizeInput: Fix handling of character(1) choices
* Re-document
* Add .github to .Rbuildignore
* Expand comment, don't import stats
* Add test for 013-selectize regression
* Expand comment
* Split listify into series of passes
* Thouroughly overhaul and comment choicesWithNames()
* No recursion
* Comment new "flat" choice processing machinery
* Remove unneccesary test of choice tree with depth > 2
* Test for choices idiomatically
* Tweak comment for asCharacter
* Comment odd test, add a new test for single-item list
* Handle empty non-lists correctly, add test
* Add test ensuring empty lists come back named
* Add comment/assertion stipulating processGroupedChoices() takes only lists
Update links to help file to not use `showReactLog`, but `reactlogShow`
Use updated reactlog pkg function api of reactlog_*. This may fail right now, but rerun travis when the reactlog code is merged into master.
We already had an `immediate` input option, which was used to override client side rate
limiting mechanisms (debounce/throttle). This commit extends the semantics of that option
to also mean that duplicate values should not be ignored on the client side.
Previous to this commit, circumventing the client side dedupe logic was not enough. The
server side ReactiveValues object was also subject to deduping. With this commit, the
low-level ReactiveValues class's constructor now has a `dedupe` option, which defaults
to TRUE; the ReactiveValues used for a session's input has it turned to FALSE. I figure
if I had to work this hard to get the client to stop sending duplicates, and the input
values are only expected to ever be updated by the client, then there's really no reason
for server side deduping to be performed for this particular ReactiveValues object.
It would make sense as a future feature to also make deduping optional for user-created
reactiveValues and reactiveVal objects.
If a downloadHandler content function returns a promise (or future)
then Shiny will wait for the promise to resolve before serving up
the file download.
- Moved (in|de)crementBusyCount calls out of Context and into Observer
- decrementBusyCount is (effectively) deferred for async observers until
the async operation is complete
- invalidateLater didn't force(session), almost certainly was buggy
- invalidateLater, reactiveTimer, and manageInputs all now use a new
session$cycleStartAction, which delays their effect until observers
(including async ones) are done executing
