-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
insertUI/callModule to add, removeUI/??? to remove (no mechanism to deactivate a "server" instance) #2281
Comments
Would a work-around be to (manually) keep a list of active modules?
registering a new module or overwriting an existing one would be done with
|
In short, no. There seem to be quite a few complexities around the inner workings of the server side of the modules, especially around reactive values, (not forgetting outputs that are triggered by them!), the session (and session environment) itself and the use of observeEvent/observe. For example, when you use observeEvent/observe within the modules, there are references made elsewhere (ie registering the observe as a callback in a stack somewhere - guess?) which keep the GC from cleaning them (at least, that's what I am again guessing). Arguably the solution to this particular part might be to retain a list of all observers that the module makes and the $suspend or $destroy them manually - and recurse through the module tree into deeper modules too, (doesn't solve what to do with the session object though) |
Have there been any developments on this issue? Thanks |
I used to store observers in a reactiveValues and on removal, destroy them with their methods. But as these methods are not documented, this is quite a blind way to do and absolutely not a "good practice", just a trick. |
@earnaud That is essentially what I've ended up having to do (I use a list instead of a reactiveValues though). It works when there are only a few observe's that you are doing, but when you start writing complex apps with 50+ observes it's very easy to miss one. Is there still no progress on this from Shiny devs? |
Instead of removing each observer separately, we could remove the moduleServer() itself:
|
This would probably also solve #1797 #548 and #2040
In short, there is capability to a) modularise application server processing (by using callModule) and there is also b) capability to add/remove UI sections via a number of mechanisms, but commonly via insertUI/removeUI.
When trying to use a combination of the above we encountered the problem that there seems to be no opposite to callModule().
For example:
insertUI([target], [after], [UI of widget - with ID])
and callingcallModule([ID of UI of widget], [data])
. This would produce a UI/Server pair which hangs off the session namespace via id ID (having usedns <- NS(id)
andns("selectX")
etc).Arguably, as long as the UI/Server pair has a unique ID every time, this is workable with the cost of non-release of memory and processing of removed widgets. However, if you take the same principle and use it to serve tabs on your site which would have the same ID each time they are instantiated/selected then currently you end up with multiple server instances reacting to a single UI instance that is regenerated each time the user moves away from and back to - all due to the fact that there is no way to do the reverse of callModule() [that I know of]
NOTE: this is specifically a problem when using
output$plot <- ....
,observe({ input$selectX })
orobserveEvent(input$selectY, {})
in the sub-module/widgetThe text was updated successfully, but these errors were encountered: