Modularise codebase

[johann-wagner]

Purpose: In order to make the RShiny Dashboard as efficient as possible, I will modularise my functions, data loading, data cleaning, data wrangling, data writing, RShiny App. I expect that RShiny App to take a lot of time to load and run/"knit", so optimising these steps will be crucial, particularly making them all into R scripts instead of RMarkdown. I will have two .Rmd scripts which will have the same code content as in the aforementioned scripts, but will run these separately to the RShiny App.

TO DO (Modularisation):

• [x] Create separate scripts for each respective functions
• [x] Create setup and configuration script (Load packages + custom functions)
• [x] Create data loading R script (Load Data: Use galah API)
• [x] Create data cleaning R script (Clean Data: Exclude data)
• [x] Create data wrangling R script (Wrangle and make new month column)
• [x] Create data writing R script (Save raw and processed data as .csv files)
• [x] Create RShiny App (Create Dashboard)

TO DO (RMarkdown):

• [x] Ensure same code is used in data_cleaning.Rmd
• [ ] Extract code snippets from modularisation scripts and use them in final_report.Rmd

[johann-wagner]

Hello @DS4B-ANU and @fredjaya,

Just wanting to check in regarding this codebase structure will be suitable given the assignment instructions. I think the best approach will be to modularise my codebase using the above structure and have two .Rmd files (data_cleaning.Rmd and final_report.Rmd). This way the RShiny App uses separate scripts to create the dashboard and the two .Rmd files are separate from the dashboard to ensure that the RShiny App is as efficient as possible, as I expect this to take quite a long time to run and publish the App.

I plan to include the same code snippets (+more in the data_cleaning.Rmd file) in the .Rmd scripts. And then the rest of the final_report.Rmd file will include essentially explanations of how to use the RShiny App as well as maybe a specific case study showcasing the use cases/utility/purpose/caveats of the dashboard.

Questions/Clarifications:

• Is this approach suitable?
• Do you have any suggestions on how I can improve this structure? (I was thinking of maybe creating a driver.R script which would essentially be the one script source()ing all the relevant scripts (setup and configuration, data loading, data cleaning, data wrangling) in the correct order to prepare the data for the dashboard?

[DS4B-ANU]

@johann-wagner this seems good to me. Please do make sure that the final_report.Rmd follows the guidelines (particularly the word limit) as closely as you can. This means that we can mark things in a way that's fair across the board. If you're unsure, just bear in mind that we'll grade according to the assessment guidelines, but that there are very intentionally no specific weightings in those guidelines, so that you have flexibility within them to get a good grade in many different ways.

More specifically, the general idea of using that report to demo your shiny app is great. If you want to make it really easy for us to grade (and if the data license allows it, you should be careful there!) then you could consider publishing your Shiny app:

https://shiny.posit.co/r/getstarted/shiny-basics/lesson7/

Other than that, do what you have time for, and if you have the time at the end then putting some effort into making it user-friendly will help!

@fredjaya, any other thoughts?

[fredjaya]

Not too much to add, but agree that getting it working is key.

Modules look to be highly recommended according to mastering shiny.