Allow `invalidateLater()` to be cancelled.

[mmuurr]

I use invalidateLater() to implement custom 'polling', though there are times I want to 'bypass' the time-based invalidation (and force an invalidation sooner). Crafting a wrapper to allow that is mostly straight-forward, but in such cases I also want to clear the currently-in-flight timed invalidation (and typically reset/recreate with a fresh call to invalidateLater()).

invalidateLater() could return a zero-arg function that cancels the task (and session's registered onEnded callback, if any). Given that it currently returns invisible(NULL) and already has references to both needed clearing functions, I believe this would be:

1. backwards-compatible, and
2. consistent with other return-value-is-a-canceller APIs (including those used by invalidateLater() itself), and
3. a fairly tiny code change, replacing:
   

   shiny/R/reactives.R

   Line 1884 in 50a140c

   invisible()

   
   with:

   invisible(function() {
     timerHandle()  # clear the scheduled task
     clear_on_ended_callback()  # clear the session's onEnded callback (if any)
   })

I'm happy to generate that small PR along with tests if this is given the thumbs-up (but will save that effort if there is disapproval).

[schloerke]

I agree that that's the change that'd be needed to cancel the invalidateLater(), but is it needed?

Can't you add a trigger() to your reactive expression to force the reactive expression to execute now? Reprex shinylive.io app.

When clicking the "Update now" button, the reactive expression for r triggers immediately. The previously pending invalidateLater() is discarded and a new one is made.

I believe this fits your request.

[mmuurr]

Yes, that does fit my request!
I must have made a mistake in a small test I had ginned-up at one point 🤔.

Just for my own mental model, is the following true?:

• invalidateLater() actually does still lead to the original callback being run, and
• that callback continues to hold the reference to ctx, but
• ctx$invalidate() is now effectively a no-op since ctx has already been invalidated?

I can still imagine some situations where one may want to cancel a pending invalidation (without forcing an invalidation), but for my specific use case the existing behavior works; thanks!

[schloerke]

Just for my own mental model, is the following true?:

• invalidateLater() actually does still lead to the original callback being run, and

invalidateLater() leads to the reactive calculation to want to be re-calculated. Nothing is forced. If the output or reactive is ready to be recalculated, then it will.

But, for example, if the output is hidden (such as on another tab), the output will not attempt to recalculate.

• that callback continues to hold the reference to ctx, but

Yes... for that execution of invalidateLater(). But typically it'll run many times and it could get messy handling which handle belongs to which invalidateLater().

• ctx$invalidate() is now effectively a no-op since ctx has already been invalidated?

Correct...

shiny/R/react.R

Lines 127 to 129 in 592e825

	if (.invalidated)
	return()
	.invalidated <<- TRUE

I can still imagine some situations where one may want to cancel a pending invalidation (without forcing an invalidation),

I'd still recommend using the native reactivity to your advantage.

Ex: Make something reactive to a FALSEy when you want to cancel the invalidateLater()

Example app that will stop updating a render value and an observer: shinylive.io reprex

but for my specific use case the existing behavior works; thanks!

Awesome! Glad you're covered!

[schloerke]

Closing as method is behaving as intended.

tl/dr: Use another reactive variable to trigger req(FALSE) or within an if statement to deter calls to invalidateLater()