Overall App Structure: Modularity

[jonthegeek]

To make it easier for us to work on things at the same time, we should diligently modularize everything.

• Overall UI
  • "Study Summary" module (the card with the study name, etc)
  • "Navset" module (or very possibly just the bslib::navset_bar(), but somewhat cleaned up to "feel" more modular)
    • "Study Overview Panel" module
      • "Overview table" module
      • "Scatter plots" module
        • Multiple instances of a "scatter plot" module (one per metric).
    • "Metric Details Panel" module
      • (etc)
    • "Participant Details Panel" module
      • (etc)
    • Eventually: The ability to plug in other tab-modules.
  • "Filters" module (takes selected tab + input-values-as-reactive-values from other module-servers, updates which inputs are displayed and what's selected inside them)

An important part of this breakdown is that each thing shouldn't have to know about anything inside one of its neighbors. If it needs data from a thing deeper down, that data needs to be returned by a server module in that module family (important note: any given module can have multiple server modules, if that makes sense for a given application, each of which can return a different reactive value associated with that module, for example). I haven't finished working out how/whether this impacts the way the htmlwidgets are built.

This isn't 100% "baked" yet; I'll need to figure out what feels "right" for some pieces of it as we build. In particular the two-way communication between Shiny and the various widgets for selecting sites remains a little fuzzy for me, but I think we can get to a clean, maintainable solution.

(I was going to put some data thoughts in here, too, but I'm splitting that into its own discussion)

[jwildfire]

I think this is right on. A few stray thoughts,

• Parent ui and server functions called in RunApp() should only call modules and maybe a setup() function to help parse inputs as needed.
• Might want a global config object that gets passed around to all modules. We can discuss
• Re: "Eventually: The ability to plug in other tab-modules.", We may want to standardize this a bit and have a single framework that all of these domain-specific sub-modules have to follow. Something like safetyGraphics charts.

[jonthegeek]

(reposting here from chat, which I posted to because GitHub was down at the time)

@jwildfire Yes on the parent ui/server simplicity! And even more... most setup()-type stuff should happen in RunApp() (currently named run_app(), btw); anything that applies to all users should happen before the call to shiny::shinyApp(), so that it only runs when the overall server launches (no need for each user to re-do any data munging and such). I'll move some things in that direction before too long, most likely.

I doubt we'll want a config object. We might have things to put in session$userData (if there are config-like things that change per user and especially that might change inside of modules), but for the most part I think config-like things will be normal function arguments. Don't group things together if there's a chance a given module won't care about something in the group, basically.

For the plugins: Yup, safetyGraphics is what I had in mind there, at least that general idea! It won't be so much that you'll be able to hook ANYTHING into a gsm.app raw, but, if you format it right, we can use it. For example, we'll likely have to know which filter(s) should display when your tab is displayed, so you'll have to tell us something about that.

---

Reply from @jwildfire:

Yep - that all makes sense to me in general. I think we're generally aligned here and ready to get to work. Can sort out next level of details as we go.