This was the product of a long discussion between @wch, @alandipert, @bborgesr
and myself. The conflation of immediate (no throttle/debounce) and non-dedupe
in a single "immediate" flag was deemed unacceptable, because UI controls often
want immediacy but also dedupe. Introducing a second "dedupe" flag would work
but {immediate: false, dedupe: false} doesn't make much sense, and dedupe not
only implies that InputNoResendDecorator should behave differently but also
InputBatchSender (i.e. no deduplication AND no coalescing).
We decided to remove the "immediate" boolean option and replace it with a
string option that would have three possibilities at this time. The only con
to this approach is if anyone is calling onInputChange with immediate:true
today, and I can't imagine anyone is. The immediate flag only has any effect
if the input id that's being set has been put in debounce/throttle mode, and
I don't even think that is documented today, and I'm not even sure it's
possible to do it from custom JS (that's not part of a custom input binding).
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.
This was introduced by some changes to shinyapp.js that were necessary
before async outputs and sync outputs were held/flushed together. Now
that async/sync outputs are held/flushed together, these changes are
not necessary and removing them fixes the problem.
The test app is in shiny-examples/205-async-req. I also moved a test
app from manualtests/async/download.R to shiny-examples/204-async-download.
* fix appendTab for empty tabsetPanels; use spread operator to avoid having to resort to apply; upgrade grunt.
* revert back to `Math.max.apply(null, existingTabIds) + 1;` there's no browser compatibility issues there
* NEWS item
* added `onStop` arg to `shinyApp()` (and renamed our internal `onEnd` - which is what was calling `on.exit()` already - to `onStop` as well)
* added onStop() function
* add entry for documentation
* make it work for all possible app structures (interactive, saved as app.R, saved as ui.R and server.R)
* fix#1772: make sure `onStart` works in all scenarios
* update NEWS
* improved wording
* more wording
* and more wording
* don't stop execution if a `onStop` callback function results in an error
* remove "(all sessions have been disconnected)" because it's misleading
* add @seealso documentation
* shamefully forgot to Cmd Shift D
* change code place
* Code review feedback
* onStop: use session argument instead of scope
Squashed commit of the following:
commit 8667bed8962069a5cab8691f981e2b7ba9d449c3
Author: Winston Chang <winston@stdout.org>
Date: Tue Jul 11 14:36:11 2017 -0500
Edits
commit c4e8549ca5
Author: Konrad Rudolph <konrad.rudolph@gmail.com>
Date: Fri Jul 7 17:57:33 2017 +0100
Describe changes
commit 7b05c2e60f
Author: Konrad Rudolph <konrad.rudolph@gmail.com>
Date: Fri Jul 7 17:54:40 2017 +0100
Add new function to doc index
commit eb93ebfad8
Author: Konrad Rudolph <konrad.rudolph@gmail.com>
Date: Fri Jul 7 17:54:30 2017 +0100
Add documentatio for new function
commit 1a6c8a4d72
Author: Konrad Rudolph <konrad.rudolph@gmail.com>
Date: Fri Jul 7 17:53:13 2017 +0100
Add a function to test whether the app is running
* - Convert all example apps to single file app.R file
- Make relevant updates to Readmes to match up with app.R structure
- Add color to plots (RStudio blue)
- In 04_mpg example: Show outliers by default, as opposed to hide, since this is more routine
- In 06_tabsets and 08_html examples: Don't name random data vector "data"
- Add extensive comments to app.R files and use consistent formatting of comments across examples
- In 09_upload example: Use req() to check for NULL entry
* add news entry summarizing changes
* use true RStudio blue, #75AADB
* Conver shinyApp calls at the end to drop argument name in examples 3-11, except for the custom HTML example. Kept them in for examples 1&2 for completeness in first exporuse to function.
* Pull news items that got added before this PR was merged
* Update comment for shinyApp function -- it creates an app object, doesn't run the app
