Board server — board_server • blockr.core

A call to board_server(), dispatched on objects inheriting from board, returns a shiny::moduleServer(), containing all necessary logic to manipulate board components via UI. Extensibility over currently available functionality is provided in the form of S3, where a board_server() implementation of board sub-classes may be provided, as well as via a plugin architecture and callback functions which can be used to register additional observers.

Usage

board_server(id, x, ...)

# S3 method for class 'board'
board_server(
  id,
  x,
  plugins = board_plugins(x),
  options = board_options(x),
  callbacks = list(),
  callback_location = c("end", "start"),
  ...
)

Arguments

id: Parent namespace
x: Board
...: Generic consistency
plugins: Board plugins as modules
options: Board options (NULL defaults to the union of board, block and registry sourced options)
callbacks: Single (or list of) callback function(s) registering additional observers. Each receives a visibility list with three channels, required, visible and frozen, each an environment of per-block reactiveVals (core keeps one per board block as blocks are added and removed). Declare a block needed with visibility$required[[id]](TRUE) (or FALSE for built but dormant) and report the view it is rendered into with visibility$visible[[id]](view) (or NA_character_ for off screen); the board reads both to gate construction, evaluation and rendering. Set visibility$frozen[[id]](TRUE) to freeze a block's inputs (for example when its controls are hidden), so a forged input can no longer steer it.
callback_location: Location of callback invocation (before or after plugins)

Value

A board_server() implementation (such as the default for the board base class) is expected to return a shiny::moduleServer().

Active conditions

Conditions raised while blocks evaluate (errors, warnings and messages) are exposed as a reactive data frame board$conditions on the read-only board handed to plugins and callbacks, with one row per active condition and columns block, phase, severity, message and id. It combines the per-block server$conditions reactives (see block_server()), so a consumer reads a single reactive — the whole board, or one block's frame for fine-grained updates — rather than walking nested condition state. The default notify_user() plugin renders its toasts from this source.