Configuration File

The configuration YML file provides the wiring instructions for generating the shinyapp R files. Hence, it is important for the app developer to pay attention and understand this file . By default the file is named config.yml you can change this name to suit to your needs.

The information below describes the config.yml structure and defaults.

Top Level

Property and default value	Details
dashboard_template: bs4_dash	At this time on bs4_dash is only supported
template_file: !expr system.file(“bs4/bs4_standard.mst” , package = “shinyspring”)	Supports bs4_minimal.mst bs4_standard.mst
code_gen_location: ‘.’	where will the code be created
dummy_test.mod_name: dummy_mod dummy_test.weird_param: dummy	Leave this as it is. It is there to overcome a bug
shinyspring_config : config.yml	Recommendation to keep config.yml . If you change take care to change all defaults downstream in build chain
preload_dataset: true	At this only only true works. Future support will give option to turn this off
source_file_onstartup: on_startup.R	names the the file that needs to be sourced before shinyapp launches. If you change take care to change all defaults downstream in build chain

Dataset Configuration

Shown below is a basic example of loading 3 datasets into the shinyspring environment

• all datasets follow the convention of ds.[ds_name].[ds_param]

• all datasets need to atleast have the ds_params of a type and connection defined.

  • For type We currently support csv , rds , feather , parque , custom

  • custom calls the functions you specify. This provides an approach to load any dataset. In example below read_product_map() will be called at startup time.

    ds.product_map.type: custom
    ds.product_map.connection: read_product_map()

• ds_info (optional) is a neat way of providing meta information for dataset. You can change colnames , change data types for columns , provide readable colnames (pretty names) , validate NA threshholds via ds_info . ds_info as two ds_params

  • ds_info_type options can be csv , google and excel. Refer Sample for defining ds_info .

  • ds_info_url connection info for CSV(local) , googlesheet(URL https) , excel (local) Sample here [TODO]

• Other optional ds_params :

  • subset limit the dataset to a subset number of rows. Eg: 1000

  • pretty_names provide readable colnames that can be used in UI

    ds.mexico.subset: 100
    ds.mexico.pretty_names: !expr c("plaintiff" , "type" , "y96", "y97")

Menus

Wiring menu’s requires a bit more care as we rely on Whisker/Mustache5 based templating for nested structures which can be little bit more involved. Sample menu structure is provided below.

 menus: [
    { title: Introduction , name: intro_tab , icon: university  },
    { title: Core Analysis , name: core_tab , icon: indent  },
    { title: Data Exploration ,  icon: chart-bar ,  parent_menu: true ,
       sub_menu: [
         {first:  true ,submenu_title: Visualize , submenu_name: explore_tab , submenu_icon: circle-thin } ,
         {last_submenu:  true , submenu_title: Correlations , submenu_name: corr_tab , submenu_icon: cubes } ,
       ]
    },
    { title: Credits , name: credits_tab , icon: heart , last_menu: true }
  ]

• menus is a Level 1 nested structure

• title the text label that will be visible in menu

• name internal reference to the linked shinyspring based shinymodule. this name is used later when defining the shiny modules. Provide unique name as the module and tab are linked via this name

• icon the icon for menu. These are font awesome names

• parent_menu for menu items with sub_menuitems , make sure you specify this else the generated app.R will have incorrect comma’

• sub_menu Level 2 nested menu structure

• first and last_submenu need to mark the start and end of submenu items so that the comma’s can be correctly placed in the code

• submenu_title similar to title but for sub_menu

• submenu_name similar to name but for sub_menu. Provide unique name as the module and tab are linked via this name

• submenu_icon similar to icon but for sub_menu. These are font awesome names

• last_menu needs to be marked to make sure that comma’s are created correctly in code.

• Notes:

  • Menu’s can be Level 1 and Level 2. Level 3 and beyond are not supported.

Modules

Modules are defined with the pattern [module name].[module property]: value . Structure sample below

  custom_mod.mod_name: dummy_mod
  custom_mod.ui_function: dummy_mod_ui
  custom_mod.server_function: dummy_mod_server
  custom_mod.onload_function: dummy_mod_onLoad
  custom_mod.param1: param 1
  custom_mod.param2: param 2

• [module name] can be tab name in menus (typically) , or any module you want (rare). You can reference the module properties in code by calling mod_registry$params_for_mod(mod_name) in your code

• Modules are two types

  • Published : Formal package based modules published on github and registered in module registry . For these modules most of the default properties are already set and as app developer you need to wire the mandatory and maybe the optional params. Refer Mod Registry concepts here

  • Custom : This is the module you are writing this

Authentication

Authentication support is based on shinymanager package It is not fully developed. You can try the preview version with the following in configuration file

basic_auth: true

Scheduling

targets package