This warning was happening to dependent packages on R CMD check.
The problem is due to delayedAssign; it appears this can't be used safely, at least not to define package-level symbols that contain S4 or reference class objects.
If you call this in a package's .R file:
`delayedAssign("hello", stop("boom"))`
but don't refer to "hello" anywhere, when you run R CMD check on a dependent package you'll see the error.
If the expression needs the methods package (like Context$new()), you'll get an error unless the dependent package itself depends on methods.
Ref:
https://groups.google.com/d/msg/shiny-discuss/cgSHsM1FCjY/vgU1-jmkGjkJ
The user reported that on a page with multiple uiOutputs whose corresponding
renderUI calls all returned sliderInputs (but no sliderInput was present in
ui.R), some but not all of the sliders were initialized correctly; the ones
that were not didn't receive the jquery-slider treatment and just looked like
text boxes.
This was caused by a fundamental flaw in our handling of singletons in
renderUI. The implicit assumption in the old renderUI code was that:
1) Any HTML we generate in renderUI would be rendered in the client
2) Given multiple calls to renderUI, the HTML we return will be rendered in
the client in the order that we generated it
Both assumptions are incorrect. #1 would be incorrect in cases where an output
is rendered twice before flushOutput is called (this is possible when using an
observer to modify a reactive input, for example), and #2 is incorrect when
output is flushed with multiple values (very common, and exactly what was
happening to the user scenario linked above).
This commit fixes the problem by deferring singleton-handling for uiOutput to
the client. We don't assume that a singleton has been rendered until right
before we render it. The implementation uses a surroundSingletons function on
the server side to surround all singletons with <!--SHINY.SINGLETON[sig]-->
and <!--/SHINY.SINGLETON[sig]-->, which will then be parsed and removed in
the htmlOutputBinding in shiny.js. (And because singletons may contain <head>
elements, we also need to defer <head> hoisting to htmlOutputBinding as well.)
The context$filter mechanism previously used in tagWrite was not flexible
enough to handle this kind of singleton processing. The new rewriteTags
function does tag walking and rewriting much more robustly and flexibly than
context$filter, so I also refactored renderTags to use it instead.
One unrelated problem I noticed was that singleton only worked reliably on
tags, possibly on characters and definitely not on list() or tagList(). This
is because list flattening was happening at tag construction time, which
can cause singleton objects to be trampled. (Among other reasons, such as
context$filter not being called on list objects.) I changed tags.R to not do
any flattening or NULL dropping at tag construction time, but instead to do
it at the last minute during tagWrite.
This bug was introduced in 3fc1410. Essentially it boils down to the difference between stringifying a factor, and stringifying a list containing a factor:
> as.character(factor('a'))
[1] "a"
> as.character(list(factor('a')))
[1] "1"
The call to split that was introduced in this commit ends up generating lists of factors, not vectors of them.
The best fix I could find was to convert all the attribute values to character before doing the split.
Observers can now take priority levels, which allow the user to control
the order of execution. Note that reactive expressions do not have
priority levels; since they are lazily evaluated, it wouldn't make any
sense to speak of priorities.
Another commit will be needed to add an API for changing the priorities
of outputs (probably in outputOptions?).
