EVOLUTION-MANAGER

Edit File: debounce.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>R: Slow down a reactive expression with debounce/throttle</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href="R.css" />
</head><body>

<table width="100%" summary="page for debounce {shiny}"><tr><td>debounce {shiny}</td><td style="text-align: right;">R Documentation</td></tr></table>

<h2>Slow down a reactive expression with debounce/throttle</h2>

<h3>Description</h3>

<p>Transforms a reactive expression by preventing its invalidation signals from
being sent unnecessarily often. This lets you ignore a very &quot;chatty&quot; reactive
expression until it becomes idle, which is useful when the intermediate
values don't matter as much as the final value, and the downstream
calculations that depend on the reactive expression take a long time.
<code>debounce</code> and <code>throttle</code> use different algorithms for slowing down
invalidation signals; see Details.
</p>

<h3>Usage</h3>

<pre>
debounce(r, millis, priority = 100, domain = getDefaultReactiveDomain())

throttle(r, millis, priority = 100, domain = getDefaultReactiveDomain())
</pre>

<h3>Arguments</h3>

<table summary="R argblock">
<tr valign="top"><td><code>r</code></td>
<td>
<p>A reactive expression (that invalidates too often).</p>
</td></tr>
<tr valign="top"><td><code>millis</code></td>
<td>
<p>The debounce/throttle time window. You may optionally pass a
no-arg function or reactive expression instead, e.g. to let the end-user
control the time window.</p>
</td></tr>
<tr valign="top"><td><code>priority</code></td>
<td>
<p>Debounce/throttle is implemented under the hood using
<a href="observe.html">observers</a>. Use this parameter to set the priority of
these observers. Generally, this should be higher than the priorities of
downstream observers and outputs (which default to zero).</p>
</td></tr>
<tr valign="top"><td><code>domain</code></td>
<td>
<p>See <a href="domains.html">domains</a>.</p>
</td></tr>
</table>

<h3>Details</h3>

<p>This is not a true debounce/throttle in that it will not prevent <code>r</code>
from being called many times (in fact it may be called more times than
usual), but rather, the reactive invalidation signal that is produced by
<code>r</code> is debounced/throttled instead. Therefore, these functions should be
used when <code>r</code> is cheap but the things it will trigger (downstream
outputs and reactives) are expensive.
</p>
<p>Debouncing means that every invalidation from <code>r</code> will be held for the
specified time window. If <code>r</code> invalidates again within that time window,
then the timer starts over again. This means that as long as invalidations
continually arrive from <code>r</code> within the time window, the debounced
reactive will not invalidate at all. Only after the invalidations stop (or
slow down sufficiently) will the downstream invalidation be sent.
</p>
<p><code style="white-space: pre;">ooo-oo-oo---- =&gt; -----------o-</code>
</p>
<p>(In this graphical depiction, each character represents a unit of time, and
the time window is 3 characters.)
</p>
<p>Throttling, on the other hand, delays invalidation if the <em>throttled</em>
reactive recently (within the time window) invalidated. New <code>r</code>
invalidations do not reset the time window. This means that if invalidations
continually come from <code>r</code> within the time window, the throttled reactive
will invalidate regularly, at a rate equal to or slower than than the time
window.
</p>
<p><code style="white-space: pre;">ooo-oo-oo---- =&gt; o--o--o--o---</code>
</p>

<h3>Limitations</h3>

<p>Because R is single threaded, we can't come close to guaranteeing that the
timing of debounce/throttle (or any other timing-related functions in
Shiny) will be consistent or accurate; at the time we want to emit an
invalidation signal, R may be performing a different task and we have no
way to interrupt it (nor would we necessarily want to if we could).
Therefore, it's best to think of the time windows you pass to these
functions as minimums.
</p>
<p>You may also see undesirable behavior if the amount of time spent doing
downstream processing for each change approaches or exceeds the time
window: in this case, debounce/throttle may not have any effect, as the
time each subsequent event is considered is already after the time window
has expired.
</p>

<h3>Examples</h3>

<pre>
## Only run examples in interactive R sessions
if (interactive()) {
options(device.ask.default = FALSE)

library(shiny)
library(magrittr)

ui &lt;- fluidPage(
  plotOutput("plot", click = clickOpts("hover")),
  helpText("Quickly click on the plot above, while watching the result table below:"),
  tableOutput("result")
)

server &lt;- function(input, output, session) {
  hover &lt;- reactive({
    if (is.null(input$hover))
      list(x = NA, y = NA)
    else
      input$hover
  })
  hover_d &lt;- hover %&gt;% debounce(1000)
  hover_t &lt;- hover %&gt;% throttle(1000)

output$plot &lt;- renderPlot({
    plot(cars)
  })

output$result &lt;- renderTable({
    data.frame(
      mode = c("raw", "throttle", "debounce"),
      x = c(hover()$x, hover_t()$x, hover_d()$x),
      y = c(hover()$y, hover_t()$y, hover_d()$y)
    )
  })
}

shinyApp(ui, server)
}

</pre>

<hr /><div style="text-align: center;">[Package <em>shiny</em> version 1.5.0 <a href="00Index.html">Index</a>]</div>
</body></html>