<em>Despite their advantages, Dynamic Shiny Modules can destabilize the Shiny environment and cause its reactive graph to be rendered multiple times. In this blogpost, I present how to remove deleted module leftovers and make sure that your Shiny graph observers are rendered just once. If you'd like to watch an updated tutorial on this subject, be sure to check out the Appsilon Shiny Conference tutorial on Dynamically adding and removing Shiny modules by Jonas Hagenberg. </em> While working with advanced Shiny applications, you have most likely encountered the need for using <a href="https://shiny.rstudio.com/articles/modules.html" target="_blank" rel="nofollow noopener">Shiny Modules</a>. Shiny Modules allow you to modularize the code, reuse it to create multiple components using single functions, and prevent the code’s duplication. Perhaps the best feature of Shiny Modules is the ability to create dynamic app elements. A great implementation of this can be found <a href="https://shiny.ogustavo.com/add_remove_module/" target="_blank" rel="nofollow noopener">here</a>. This particular example provides convenient logic for adding and removing variables and their values in a reactive manner. Implementing Shiny Modules does come with certain challenges that can affect the stability of your Shiny environment. In this article, I will show you how to overcome them. <h2><b>Removing the remnants of an obsolete, dynamic Shiny module</b></h2> Removing a module can have a destabilizing impact on your Shiny app environment. To illustrate this problem, let’s consider this simple <a href="https://github.com/Appsilon/dynamic-shiny-modules/blob/master/before.R" target="_blank" rel="noopener">application</a>: <img class="size-full wp-image-15502 aligncenter" src="https://webflow-prod-assets.s3.amazonaws.com/6525256482c9e9a06c7a9d3c%2F65b0222684ab67fae7ead1b7_creating-and-removing-Shiny-module-click-counter-1-1.gif" alt="creating and removing Shiny module click counter" width="298" height="191" /> The app allows the user to create (and remove) a new module that counts the number of clicks of the button placed inside of the module. The number of clicks is also displayed outside the module in order to see the internal module value after that module is removed. The expectation is that removing the module would remove its internal objects including input values. Unfortunately, this is not the case: <img class="size-full wp-image-15506 aligncenter" src="https://webflow-prod-assets.s3.amazonaws.com/6525256482c9e9a06c7a9d3c%2F65b02228790b9e1ad89024d9_problem-with-removing-internal-objects-like-input-values-in-Shiny-module-2-1.gif" alt="problem with removing internal objects like input values in Shiny module" width="297" height="188" /> In fact, removing the module only affects the UI part while the module’s reactive values are still in the Shiny session environment and are rewritten right after a new module is called. This becomes particularly problematic when the module stores large inputs. Adding a new module aggregates the memory used by the application and can quickly exhaust all the available RAM on the server hosting your application. This issue can be resolved by introducing the <i>remove_shiny_inputs</i> function, as explained <a href="https://www.r-bloggers.com/shiny-add-removing-modules-dynamically/" target="_blank" rel="nofollow noopener">here</a>. The function allows you to remove input values from an unused Shiny module. In our implementation, making use of the function requires a simple modification of the remove_module event: <table> <tbody> <tr> <td> <figure class="highlight"> <pre><code class="language-r" data-lang="r">  observeEvent(input$remove_module, {     removeUI(selector = "#module_content")     shinyjs::disable("remove_module")     shinyjs::enable("add_module")     remove_shiny_inputs("my_module", input)     local_clicks(input[["my_module-local_counter"]])   }) </code></pre> </figure> </td> </tr> </tbody> </table> <img class="size-full wp-image-15510 aligncenter" src="https://webflow-prod-assets.s3.amazonaws.com/6525256482c9e9a06c7a9d3c%2F65b02229aae8a26201c274a4_remove_module-event-Shiny-3-1.gif" alt="remove_module event Shiny" width="296" height="189" /> <h2><b>Removing internal observers that have registered multiple times</b></h2> The second issue has likely contributed to hair being pulled out of many Shiny programmers’ heads. Observe events, just like reactive values in the example above, are not removed when a module is deleted. In this case, the issue is even more serious –  the obsolete observer is replicated rather than overwritten. As a result, the observer is triggered as many times as the new module (with the same id) was created. In our example, adding a simple print function inside an observeEvent shows the essence of this issue: <table> <tbody> <tr> <td> <figure class="highlight"> <pre><code class="language-r" data-lang="r">observeEvent(input$local_counter, {     print(paste("Clicked", input$local_counter))     local_clicks(input$local_counter)   }, ignoreNULL = FALSE, ignoreInit = TRUE) </code></pre> </figure> </td> </tr> </tbody> </table> <img class="size-full wp-image-15504 aligncenter" src="https://webflow-prod-assets.s3.amazonaws.com/6525256482c9e9a06c7a9d3c%2F65b0222bdf8856ddfa0e4d3d_observeEvent-in-Shiny-module-4-1.gif" alt="observeEvent in Shiny module " width="335" height="444" /> &nbsp; This behavior may cause your application to slow down significantly within just a few minutes of use. The fastest solution to this problem is a workaround that requires the developer to create new modules with unique identifiers. This way, each new module creates a unique observer and the previous observers are not triggered anymore. The proper solution, not as commonly known, is offered directly by the Shiny package and does not require any hacky workarounds. We begin by assigning the observer to the selected variable: <table> <tbody> <tr> <td> <figure class="highlight"> <pre><code class="language-r" data-lang="r">my_observer <- observeEvent(...) </code></pre> </figure> </td> </tr> </tbody> </table> The my_observer object now allows us to use multiple, helpful methods related to the created observer. One of them, <i>destroy()</i>, provides for correctly removing a Shiny observer from its environment, with: <table> <tbody> <tr> <td> <figure class="highlight"> <pre><code class="language-r" data-lang="r">my_observer$destroy() </code></pre> </figure> </td> </tr> </tbody> </table> We have two options to apply this solution to our example. The first approach calls for assigning the module’s observer to a variable that is accessible from within the Shiny server directly. For instance, we can use reactiveVal which is passed to the module and designed to store observers.  The second approach makes use of the session$userData object (<a href="https://appsilon.com/super-solutions-for-shiny-architecture-1-of-5-using-session-data/" target="_blank" rel="noopener">see Marcin’s related blog post</a>). We decided to use the second approach, so we assigned an observer to the `session$userData$my_observer` variable: <table> <tbody> <tr> <td> <figure class="highlight"> <pre><code class="language-r" data-lang="r">session$userData$clicks_observer <- observeEvent(...) </code></pre> </figure> </td> </tr> </tbody> </table> Then, we modified the remove_module event by adding a destroy action on the variable we just created: <table> <tbody> <tr> <td> <figure class="highlight"> <pre><code class="language-r" data-lang="r">  observeEvent(input$remove_module, {     removeUI(selector = "#module_content")     shinyjs::disable("remove_module")     shinyjs::enable("add_module")     remove_shiny_inputs("my_module", input)     local_clicks(input[["my_module-local_counter"]])     session$userData$clicks_observer$destroy()   }) </code></pre> </figure> </td> </tr> </tbody> </table> The result met our expectations: <img class="size-full wp-image-15508 aligncenter" src="https://webflow-prod-assets.s3.amazonaws.com/6525256482c9e9a06c7a9d3c%2F65b0222b2829666b590d883c_remove_module-event-in-Shiny-modules-5.gif" alt="remove_module event in Shiny modules" width="335" height="391" /> &nbsp; The final application code is available <a href="https://github.com/Appsilon/dynamic-shiny-modules/blob/master/after.R" target="_blank" rel="noopener">here</a>. <h2><b>Conclusion - removing dynamic Shiny modules</b></h2> Shiny offers great functionalities for creating advanced, interactive applications.  Whilst this powerful package is easy to use, we still need to properly manage the application’s low-level objects to ensure optimal performance. If you have any examples of how you struggled with solving other less common Shiny challenges, please share in the comment section below! <h2>Follow Us for More</h2><ul><li style="font-weight: 400;">Follow <a href="https://twitter.com/appsilon">@Appsilon</a> on Twitter</li><li style="font-weight: 400;">Follow Appsilon on <a href="https://www.linkedin.com/company/appsilon">LinkedIn</a></li><li style="font-weight: 400;">Try out our R Shiny <a href="https://appsilon.com/opensource/">open source</a> packages</li></ul>