An in-depth update on strategies for sharing data across Shiny modules in R, revisiting the 'stratégie du petit r' pattern (using reactiveValues() as shared state) in response to public criticism. The author defends the approach while acknowledging its pitfalls, emphasizing that naming conventions and proper scoping (using multiple reactiveValues() at different levels) are key to avoiding unmaintainable code. Additional patterns covered include passing reactive objects as function parameters, using R6 objects combined with the {gargoyle} trigger package, session$userData, package-level environments, and external databases like {storr}. The post stresses that no pattern prevents bad code—discipline and context matter most.
Table of contents
Discovering {shiny} modulesWhat is a {shiny} moduleSharing data across modulesConclusionSort: