Is there a "syntax" of Shiny UI pages?


#1

Some Shiny doc pages say that a UI element should contain specific other elements (e.g., a tabsetPanel should contain tabPanel elements); others just say they contain “elements” without further comment.

I get the feeling there is a “syntax” or hierarchy to the UI elements; rules for what can go where. But I’ve never seen a definitive statement of such structure. I’m pretty sure I can’t put a splitLayout inside a column, but nothing actually says that.

Are there rules for what goes where? Limitations? Just some guidelines? I’d like to know the boundaries of my sandbox.


#2

shiny UI elements are just html tags that are wrapped in r functions. So as far as limitations, it is only limited by what you are able to do within HTML, since what isn’t provided in a shiny function you can create yourself using the tags$ function call.

As for placing a splitLayout() call inside a column() call, you certainly can do that. It will just contain the elements within the splitLayout div within the column div. Try typing the UI elements directly into the R console and you will get the raw HTML output.

column(width = 3, splitLayout())
<div class="col-sm-3">
  <div class="shiny-split-layout"></div>
</div>

#3

Thanks for the note, @tbradley. I understand that the UI element are HTML strings and we can combine them at will. I’m wondering about the design vision behind the elements.

  • Some elements are top level, intended to hold an entire page (think flowLayout).
  • Some appear to be panel elements, to organize their contents.
  • Some have a clear, low-level purpose (titlePanel).

I think the designer had all this in mind. Did he/she enumerate the interrelationships? I don’t recall seeing that.

PS - Just for the record, I’ll never put a splitLayout inside a column. That was an extreme example of something that is allowed but seemingly absurd.


#4

Well i certainly can’t speak for the designer. However, i know some top-level elements (e.g. navbarPage) are based on bootstrap libraries and designs. You may find more info on the design vision by looking at the bootstrap docs, but i don’t have any specific references to give at the moment.


#5

Thanks! That’s an excellent point. I hadn’t made the obvious connection, between Bootstrap and Shiny, and how the design of one informed the design of the other. I’ll look for the answer there.


#6

Additonally, a lot of those top-level elements will inherit styling. So if you go to the developer tools in your web browser (hit F12 in chrome) and navigate to the element your interested in, the styling options for that element may shed some light on where that elements design came from. In the case of navbarPage, alot of the styling for the top-level elements will inherit bootstraps navbarpage libraries default styles.


#7

Loosely,

  • layouts contain both panels and controls, their primary job is to arrange their children in some kind of orientation relative to each other. (fluidRow, fixedRow, fillPage, fillRow, and fillCol probably fall into this category as well) You should expect something pretty different than HTML’s default left-to-right, top-to-bottom flow layout, generally.
  • panels tend to just wrap some contents, but their childrens’ relative layout within the panel tends to be pretty normal HTML behavior.
  • It’s fine to nest layouts inside of panels if that’s what floats your boat–for example, you could have a sidebarLayout inside of a tabPanel. However I agree that many such combinations are not going to make any sense.

I don’t want to pretend like there was some grand unifying vision here, this is the first time I’ve consciously thought about the difference between layout and panel.


#8

Thank you, @jcheng! Actually, this is more useful than you might think. I’ve been wondering until now, “Am I doing this all wrong? Am I violating Joe’s Grand Unifying Vision of page layout?” So in a funny way, it’s liberating to know I’m not.

Based on your comments here, I reworked a couple of pages, taking more liberties to put stuff where I wanted and how I wanted. The pages work better now.

Thanks, too, for the specific observations regarding layouts and panels. That will guide my design thinking.