Modul-specific data

[CorradoLanera]

(this could be related to #6 )

Suppose I have data computed (and updated) at each update of the package. Put them as internal(/exported) objects could be suboptimal because one should remember to re-run their defining code every time (so, I cannot use the solution proposed by @ColinFay).

Moreover, I can have many modules, each one, including some or many of that kind of data. To follow the solution purposed by @soetang (here, in issue #6 ), I see two ways:

1. put all data of all the module in ... your global code (pro: safer respect to multiple objects with the same name; cons: messy and lose the link with corresponding modules)

2. for each module, define an object module_xyz_data <- {} in which put all that kind of data, and next put module_xyz_data in ... your global code (pro: data for a module are defined inside the same file of the UI and server module itself; cons: high probability of defining multiple objects in distinct modules with the same name, issues which could also be extremely difficult to debug)

So, my solution is to include the server module in a function as suggested by @hadley (in https://mastering-shiny.org/action-modules.html#module-server) and put the data in between respect the two calls:

xyzServer <- function(id) {

  # my (non-reactive) module-data 

  callModule(id = id, function(input, output, server) {
    ns <- session$ns
    # my server function using my modul-data
  })
}

pro: data are next to their usage, names cannot clash, and they are correctly defined in isolation between other modules
cons: they are computed at each call of the module (or at least each time the module is called in the app_server function if it is used multiple times there), while they could be called only once at each update of the package/start of the app (as it would happen if they were defined in the global.R or solutions 1. and 2. from the @soetang suggestion)

Some of you can suggest some solutions to avoid the last cons maintaining all the pros? Are some disadvantages I did not consider in my solution that implies it is better to avoid it?

[ColinFay]

This is an old issue, but if ever someone comes across this, here is my solution.

Here is my understanding of your need:

-> Each module has its own data, that need to be recomputed every time the package update.

• mod_a has data_a
• mod_b has data_b
• mod_c has data_c

-> What is the best way to include the data for each module ?

• in data-raw: downside is you'll need to recompute the data everytime
• in xyzServer <- function(id) {: downside id the data are recomputed every time someone launches the app.

My advice :

• Instead of computing it inside the server function, compute it just before :

xyz_data <- get_xyz_data()

xyzServer <- function(id) {

  callModule(id = id, function(input, output, server) {
    ns <- session$ns
   # use of xyz_data
  })
}

That way, the data is computed at app launch (so just once by R session, instead of once by user session).

Hope this helps,

Colin