Feature: Main ui & server functions

[jonthegeek]

Feature Details

The functions that are currently ui and server should take dfResults, dfGroups, dfMetrics, and dfBounds as arguments, and return the resulting ui object and server function, respectively. By initializing a "raw" ui and then updating with the data, we're making the app slower and more fragile than it needs to be. All the data checking can happen when the app launches overall; it doesn't need to happen per-user (which is what we're doing right now). Likewise, we shouldn't have code in the server that goes to each user that handles what to do when dfGroups loads for the first time, because that is always the same (for every user); we can set that stuff up in the ui itself.

While we're at it, these functions should have more-specific names, to avoid collisions. Our ui function builds a gsm-specific UI, so gsm_ui or initialize_gsm_ui would be more appropriate. Similarly, our server function is a gsm-specific server function, so gsm_server or initialize_gsm_server is more appropriate.

Example Code

Possible Implementation

This can be rough to wrap your mind around, particularly for the server function, since we'll return a function, which has data built into it. But it will make things run much better/cleaner.

Additional Comments

[taylorrodgers]

Hey @jonthegeek, your recommendation makes sense.

To re-phrase, we want to replace lines of code like textOutput("text_output_name") and output$text_output_name and simply pass the value directly to gsm_ui. In this example, that would be dfGroups$Value[dfGroups$Param == "nickname"]?

I think when I wrote this, I had assumed we'd one day add a study drop down filter. I'm still quite curious how the user will select the study they're interested in, but that's a discussion for another day.

[jonthegeek]

Oh let's hold off on this for now. I'm pretty sure we're going to end up making (most of?) the input data reactive so it can be updated automatically via a database connection (for example). Assuming we do, we'll need to set everything in the server still, so we'll undo some of the stuff this ticket calls for.

I think our server generator should return a server function (with the reactive inputs "baked in"), but that will be a small change overall (slightly changing where some pieces of the call occur), but I need to look at the code to figure out exactly what I mean by that 😊

[jonthegeek]

Updated thought: We should pass shiny::isolated()ed versions of the data to the UI function, and set everything up with those. We'll then pass whatever comes in on to the server function, and use shiny::is.reactive() to decide if we have to do anything fancy with it (or possibly we'll wrap anything that isn't reactive in shiny::reactive() at the start to make all the downstream code the same). It will probably be common for the data to be static (possibly with redployments of the app when something changes), so let's not throw away all the good potential for the rarer case.