The return value of bootstrapPage() has changed in an unfortunate way

[cpsievert]

With the current CRAN version of shiny (1.5.0):

> str(bootstrapPage())
List of 3
 $ : NULL
 $ : NULL
 $ : list()
 - attr(*, "class")= chr [1:2] "shiny.tag.list" "list"
 - attr(*, "html_dependencies")=List of 1
  ..$ :List of 10
  .. ..$ name      : chr "bootstrap"
...

With the development version (> 1.5.0):

> str(bootstrapPage())
List of 4
 $ :function ()  
  ..- attr(*, "srcref")= 'srcref' int [1:8] 83 15 126 3 15 3 83 126
  .. ..- attr(*, "srcfile")=Classes 'srcfilecopy', 'srcfile' <environment: 0x7fbefe65d950> 
  ..- attr(*, "class")= chr "shiny.tag.function"
 $ : NULL
 $ : NULL
 $ : list()
 - attr(*, "class")= chr [1:2] "shiny.tag.list" "list"

This means, user code that does something like this will now break:

x <- bootstrapPage()
tagAppendAttribute(x[[3]], class = "navbar")

We can do better to not break this code if {bslib} isn't being used, but the structure will likely have to change if {bslib} is being used.

Some relevant discussion/use-case radiant-rstats/radiant.data#26 (comment)

[vnijs]

Question: Does this mean that if bslib is used, tagAppendAttribute() likely won't work? I'm definitely interested in bslib but would still need a way to dynamically update the right-navbar to show directory and/or Rstudio project information.

[cpsievert]

Does this mean that if bslib is used, tagAppendAttribute() likely won't work?

No, but it does means that the way in which you're using tagAppendAttribute() will have to be different when the bootstrapPage() (or fluidPage(), navbarPage(), etc) has a theme set to a bslib::bs_theme() object. In particular, the contents of the page will be included in the fourth index instead of the third (which is why I've proposed this change to radiant)

[vnijs]

Ah. So I could check the options setting you suggested and then use either the 3rd or 4th element as needed. Thanks @cpsievert!