Relative paths with Shiny and R Projects

[kaijabean]

I'm wondering what the best practice is for developing Shiny apps in conjunction with R projects.

I have a large R project, within which I'm trying to make some test Shiny apps. Basic folder structure looks like this:

myproject/ # home directory
├── myproject.Rproj # Overarching R project
├── shiny_apps/
| └── app_1/ # app root directory
| └── app.R # app file
└── scripts/
└── example_script.R # an R script that does something unrelated to the Shiny app

In the rest of my project, I set all my file paths relative to the root directory, "myproject/", either using the here package or just by specifying relative paths.

I understand that when you run a Shiny app, it understands all filepaths within it as relative to the directory where app.R is located. So e.g. if I need to load in data or source a script, I should write the filepath relative to app_1/ in order to allow the app to run properly.

However, when I'm working on the app interactively, testing things out, running code line by line, etc. (before running the app), those relative file paths don't work. Because I'm working inside of an R project, the paths get interpreted relative to myproject/, since that's the directory where the .Rproj file is located.

I think there must be a best practice for this that I'm not aware of. Am I wrong to try to create Shiny apps inside of an existing R project? Do I need to create a separate R project for each Shiny app, if I want to stick with a project-based workflow? Or is there some known workaround that's recommended for interactive Shiny development w/r/t projects?

Thank you!

[nirgrahamuk]

my preferred workflow is that every shiny app is its own project, I find it simple and efficient.

[kaijabean]

Yeah, I was thinking it might come to that. Do you know if it's okay to nest projects? Up until now, I've had everything for this assignment nicely contained in one project, and it would be awkward to break that pattern now.

[nirgrahamuk]

I dont see value in nesting projects per say. Maybe two apps need common data preparation which can be handled in a 3rd parallel project. They can all sit under a common root folder, but that needn't be a project.

[kaijabean]

I think you're right that I shouldn't be nesting projects. @jennybryan says here that there should be a one-to-one mapping between r projects, git repos, and folders on your local machine. It's just that as you say, that's really tricky in this case because I do have lots of common data prep for the apps, and up until now it's all been handled in subfolders of a single project. I may end up having to copy prepared data files over to a new project, which isn't ideal.