3.2 Using {shiny} modules

Modulizing code will be your success factor

3.2.1 Why {shiny} modules?

  1. The one million “Validate” buttons problem
  • Creating small namespaces where you can safely define ids without conflicting with other ids in the app
  • When you single app gets bigger….UI and Server exchange may be hundreds or thousands of lines apart. That is a lot of scrolling!
  1. Working with a bite-sized codebase

if you copy and paste something more than twice, you should make a function

  • {shiny} modules aim at three things:
    • simplify “id” namespacing
    • split the codebase into a series of functions
    • allow UI/Server parts of your app to be reused
  • Most of the time, modules are used to do the two first. In our case, we could say that 90% of the modules we write are never reused, they are here to allow us to split the codebase into smaller, more manageable pieces.

3.2.2 When to use {shiny} modules

  • Start right from the beginning
  • Yes, this takes a bit more time, but you will be saving yourselve volumes in the future
    • (Your future self will love you!)

3.2.3 A practical walkthrough

(Big code base example. Talk through the best way to compare) 1. Your first {shiny} module 2. Passing arguments to your modules - UseLink

3.2.4 Communication between modules

Three primary ways to share data amongst modules: - Returning a reactive function - The “stratégie du petit r” (to be pronounced with a French accent of course) - The “stratégie du grand R6”

  1. Returning values from the module
  • using reactive calls is costly on the server
  1. The “stratégie du petit r”
  • creates a sudo database shared amongst modules. More efficent, but not eloquent
  1. The “stratégie du grand R6”
  • {R6} package. The best of both worlds
  • may be foreign to some
  1. Other approaches: About {tidymodules}