WIP Frontend/backend Interface for UI Elements

[nbenn]

For many of the "actions" (e.g. add new block to stack) we have some basic (and evolving) API (e.g. add_block() in blockr).

What is much more vague currently is how the interface looks like for "presentation" aspects. A related issue here is #106.

For laying out fields of a block, we probably want this to be up to the block designer. In #106 we sketch two possible approaches¹:

• currently we have a block attribute layout that holds a function which can customize the layout
• my proposal is to instead use a generic function (or multiple) that provides (a more flexible) mechanism for extension which is more in line with the rest of the framework design

The block UI is currently provided by generate_ui.block():

https://github.com/blockr-org/blockr/blob/cec323cb8a290084fac13dd3b29f544e640ebf1c/R/ui.R#L17-L91

With this we have many implicit assumptions on what kind of behavior the frontend should support (like collapsible elements) and what kind of HTML class attributes need to be recognized (of which there's a mix of bootstrap e.g. card shadow-sm p-2 mb-2 border and our own e.g. block-validation). How can we make this cleaner?

• If we wanted to at least try to be "framework" agnostic, we need some kind of "config" framework for this. This is not impossible (and it's easier, the earlier we start doing this). We could for example do something like

  {
    "block.class": "",
    "block.card.class": "card shadow-sm p-2 mb-2 border",
    "block.card.body": "card-body p-1",
    "...": "..."
  }

  and then use this as

  div(
    class = paste(block_class, cfg$block.class),
    `data-block-type` = paste0(class(x), collapse = ","),
    `data-value` = ns("block"),
    shiny::div(
      class = cfg$block.card.class,
      shiny::div(
        class = cfg$block.card.body,
        header,
        ...
      )
    )
  )

  This way you might be able to use Material cards instead of Bootstrap cards, if you wanted to.

• If we say, bootstrap is a strict requirement because we hard-code bootstrap classes everywhere, how do we deal with bootstrap versioning? Do we fix everything to a specific bootstrap version, which the custom front-end then also has to be based on?

• We need to document our own classes well.

• If we don't allow for some more fine-grained modularity, the decisions that are made in the core package (e.g. shadow-sm for block cards) are set in stone (the only option one would have then is to re-implement everything, starting from generate_ui.block(). The config-style approach from above would alleviate this.

The stack UI is provided by generate_ui.stack():

https://github.com/blockr-org/blockr/blob/cec323cb8a290084fac13dd3b29f544e640ebf1c/R/ui.R#L95-L158

• We need to provide some hooks here, to maybe insert some JS, some custom CSS, maybe some external deps. This is easy to do, we just need to establish what kind of things need to be customizable
• This might be my ignorance: are we using different mechanisms for injecting dependencies/external code? We use htmltools::htmlDependency(), we add highlight.js as something to be fetched from externally and we add a piece of JS using tags$script(). Can this be harmonized a bit? Should we maybe bundle highlight.js?
• Use of sortable::sortable_js(): data transformations as are currently considered are mostly not associative. I don't think being able to rearrange blocks adds any value. If we really want to do this in the BMS UI we should come up with and use some mechanism for extensibility to get there.

Footnotes

1. The discussion here is not on evaluating and deciding between the two. This is tracked in How do we allow for a block implementer to control the UI? #106. ↩

[DivadNojnarg]

@nbenn. I like the idea of having a configuration class for elements in a separate file given that we don't have many UI elements: stack, block, field , + possible children tags (block header, block footer, ...). What I am more concerned about is the way we collapse elements (Bootstrap based) in the JS part: window.bootstrap.Collapse. This would have to be revised.

[JohnCoene]

I like the idea of being framework agnostics but I think it's too ambitious.

1. A CSS framework like Bootstrap is more than just classes, it often also assumes a certain DOM: a component in one framework will have another structure in another or even not exist at all. Using classes alone will not be enough.
2. We're currently Bootstrap-centric because Shiny is, if you assume users can use Material CSS via shinymaterial then we'd have to also allow (enforce?) adaptation of all inputs (fields).
3. Sorry if this one seems pesky but I don't really like the idea of a config file for this. It will be difficult for anyone, even ourselves, to map what's in the config to what's in the code. I don't think it's a nice interface, it makes iteration and the type of programming one does when designing a UI rather inconvenient.

If we want to be framework agnostics we have to developers to write their own functions, e.g.: S3 methods where we could define methods for each and every field, as well as stacks, and blocks components.

Note: this complicates quite a few things, we still need some commonality on the front-end, how we handle that?
We'd need to be able to inject components into those methods or some way to enforce the presence of certain UI components. e.g.: edit toggler, delete block button, N rows / N cols display, and more.

[JohnCoene]

Come to think of it.

It may be easier to simply create a separate "framework," we just style it how we want, without Bootstrap and it should work on all frameworks.

We could then relatively easily provide theming functions to slightly alter the look of block and stacks