The dashboard object

[nbenn]

In my mind the name of this object/class is workspace (not dashboard), but I'm open to other/better suggestions.

What kind of information does workspace encapsulate?

• The raison d'être is holding on to all stacks of an app (it is for that reason that I want to go for something like workspace over dashboard, as an app might contain multiple dashboards organized in separate tabs
• What kind of organizational structures do we have to group stacks?
  • Is it just "tabs"? What kind of metadata do we associate with tabs? Just a pretty name?
  • do we have a further level of hierarchy like "page"?
• What kind of layout information do we want to include here?
  • this is kind of the "common denominator" that all frontends should support
  • do we need things like stack width? or is this masonry specific? what about height? does number of blocks determine that? are stacks scrollable when exceeding a certain height?
  • how do we represent things like positions? as a grid?
• Are dashboards "lockable"? Or on the tab level? Is this part of workspace information?
• Do we want to allow for some piece of custom information to be part of this ("unstructured" as far as blockr is concerned?
• Does the workspace contain some UI in a sidebar (apart from the main "stacks" view) that should be represented in workspace?
• What are we missing? I'm the one who has spent the least amount of time on frontend organization...

How could something look like?

structure(
  list(
    stack_a = <stack>,
    stack_b = <stack>
  ),
  tabs = list(
    tab_a = list(
      name = "Pretty tab name",
      stacks = c("stack_a", "stack_b")
    )
  ),
  positions = list(    # or layout?
    stack_a = c(1, 1), # width = 6?
    stack_b = c(1, 2)  # width = 6?
  ),
  title = "Pretty workspace title",
  custom_settings = "[\"some json string\"]"
  class = "workspace"
)

Ar there things that seem out of scope for the MVP, but we anticipate that they will become relevant after?

[nbenn]

Conclusion of the meeting today: let's start simple. In that sense, v0.0.1 of workspace would look something like

structure(
  list(
    stack_a = <stack>,
    stack_b = <stack>
  ),
  title = "Pretty workspace title",
  settings = "[\"some json string\"]",
  class = "workspace"
)

The settings could be parsed to an R data structure, but as this is unstructured as far as the backend is concerned, parsing and re-creating a JSON string is needless.

@christophsax @JohnCoene @DivadNojnarg feel free to add to this if you have thoughts or suggestions.

[JohnCoene]

I would just not have settings be a JSON string, it can just be a list, even if it's just used by the front-end. Also we may also want some of these custom settings to be accessible server-side (e.g.: restore a server-side rendered input)

[nbenn]

@JohnCoene I'm happy to do that.

Just a note about my thinking behind keeping this as a JSON string: I did dit trying to make clear the intention that this is something that is not really meant for server-side processing in R. I thought about this as purely frontend/UI information (like how to layout blocks etc.) but I admittedly have very little idea how for example masonry manages the UI.

If some of the logic for setting up/placing UI elements is implemented server-side, then yes, parsing this to an R object makes a lot of sense. I guess we'll have to iterate a bit here to figure out how we want this to behave in the end and where to exactly draw the line between backend/frontend server/client responsibilities.