10  Shiny communication manifest

The goal of this chapter is to bring together all the concepts covered in the previous ones and get a takeaway synthesis that can be used as a reliable basis to build strong communication architecture within Shiny applications.

10.1 Communication streams

There are two communication streams in a modular Shiny app:

  • the input / output stream, dedicated to UI-server communication

  • the function parameter / return value stream, dedicated to server-server communication

It is critical to remember that both streams are targeting different activities and they most likely should never cross each other1.

10.2 Module encapsulation

Encapsulation is a key concept to keep a clear and functional architecture, especially as an application is growing and getting more complex.

  • UI / server communication should stick to the same level (namespace)
    observe inputs at the same level as where they are created

  • data (including input values from the parent) should be passed to a child through the server function parameters

  • data (including input values from a child) should be passed to a parent through the server function return value

  • both function parameters and return value can handle list objects to carry complex information

10.3 Data driven vs feature driven modules

To better organize code between tasks dedicated to user-based interactions and internal tasks like data management, an option is to think of modules being driven by their purpose:

  • data driven modules are mostly using server-server communication stream to manage and server the data

  • feature driven modules are mostly using UI-server communication stream to answer user interactions & needs

10.4 Architecture thinking

To reduce communication challenges, think about how modules will communicate to the main application and between them with:

  • global schema
    to define the global communication streams: how information goes from a module to another

  • local schema
    to define the local communication streams: how a specific module communicates with the outside

10.5 Other best practices

  • static UI should be kept on UI side to reduce code in server functions
    use of update*Input functions helps for that

  • server function parameters should be tested against reactivity

10.6 Wrap-up module

Tip

There is a specific folder in the GitHub repository attached to this book where to find a wrap-up template with both parameters & return value: wrapup-module

  1. Except for when input values are passed to other server levels through parameters and / or return values.↩︎