throughout the server modules we’ll be referencing r$proj_obj, or we will be updating it with r$proj_obj ← get_proj()
The environment stays clean. This is because the top-level of an app.R file is “global” to the Shiny session (and accessible from ui and server), but it doesn’t pollute the user’s global environment. This also means we can get rid of all the assign statements.
Because we’re running a Shiny app in another location, we need to some magic with working directories, so I introduced a this_wd variable that sets the working directory to the project folder. We store this in r too and his is passed along in the get_proj() function each time.
I decided to create one app.R file instead of separate ui, server and global files. At the top level of the app.R file, we initiate the proj_obj with:
Then in the ui part we pass along this proj_obj to the modules. This means that the modules all got new arguments.
On the server side we handle it a bit differently. We get the initiated project, and we put it in the petit
r
:throughout the server modules we’ll be referencing
r$proj_obj
, or we will be updating it withr$proj_obj ← get_proj()
The environment stays clean. This is because the top-level of an app.R file is “global” to the Shiny session (and accessible from ui and server), but it doesn’t pollute the user’s global environment. This also means we can get rid of all the assign statements.
Because we’re running a Shiny app in another location, we need to some magic with working directories, so I introduced a
this_wd
variable that sets the working directory to the project folder. We store this inr
too and his is passed along in theget_proj()
function each time.WIP.