1. freezeReactiveValue(input, "x") is called, inside a renderUI
or in an observer that then calls updateXXXInput
2. Some reactive output tries to access input$x, this takes a
reactive dependency but throws a (silent) error
3. When the flush cycle ends, it automatically thaws
What's *supposed* to happen next is the client receives the new
UI or updateXXXInput message, which causes input$x to change,
which causes the reactive output to invalidate and re-run, this
time without input$x being frozen.
This works, except when the renderUI or updateXXXInput just so
happens to set input$x to the same value it already is. In this
case, the client would detect the duplicate value and not send
it to the server. Therefore, the reactive output would not be
invalidated, and effectively be "stalled" until the next time it
is invalidated for some other reason.
With this change, freezeReactiveValue(input, "x") has a new side
effect, which is telling the client that the very next update to
input$x should not undergo duplicate checking.
Also, rename autocolors to autotheme as we'd like to support fonts and possibly more in the future
Also, wrap ggplot2 default overriding and building logic into one function, so plotly can use it in a self-contained fashion
1) In srcjs/input_rate.js line 284, the global variable `name` was
being written to.
2) In a couple of other places in that file, the global variable
`name` was being read instead of `nameType`--the result of an
incomplete refactor.
Also added an eslint rule to prevent this and other globals from
being read implicitly.
* All of these were caused by the presence of multiple body tags on the
page, which happened because networkD3's sankey plot generates SVGs
containing body tags via SVG's foreignObject tag
* In various places, the 'body' jQuery selector string is used under the
assumption there is only one 'body' tag on the page. The presence of
multiple 'body' tags breaks reliant code in strange ways.
* The fix was to use document.body or 'body:first' instead of 'body'.
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).
* Remove unused 'immediate' arguments
* Add opts argument to setInput methods
* Extract input values without opts
* Consistent interface for setting initial values
* Update NEWS
* Add binding and el when fileInputBinding triggers shiny:inputchanged
* Revert "Consistent interface for setting initial values"
This reverts commit 12c0b6e72a.
* Move InputDeferDecorater function
The new placement properly reflects the decorator stack
* Fix indentation
* bindInputs: make sure value is set immediately
* Only use opts where necessary in input decorators
* Properly send initial values
* Move initial value of .clientdata_allowDataUriScheme to better place
* Fix indentation
* Add InputValidateDecorator
* Better variable name
* Add function for default input options
* Simplify code
