mirror of
https://github.com/rstudio/shiny.git
synced 2026-02-02 10:45:06 -05:00
287f4f239e
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.