In shambhu112/shinyspring: Build Fast Shiny Applications

knitr::opts_chunk$set(echo = TRUE)

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 | | | | | | 1. bs4_minimal.mst | | | 2. 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