Closed jonthegeek closed 1 month ago
I agree this makes sense. Flexible on implementation. Might just be easiest to add an as_html
param to the report, and just return the data.frame when it's false.
I usually prefer a separate function for a different class of output. There's no harm in the existing Report_MetricTable
calling the new function as step 1 of its process.
I'll start something for this. We can always change things up on review.
Feature Details
As the lead {gsm.app} developer, in order to utilize gsm outputs without unnecessary constraints, I would like to process dfResults + dfGroups + strGroupLevel into a data.frame, that I can then display in a standardized way.
Example Code
Possible Implementation
Report_MetricTable()
has these steps at the end:I want everything above that, but I don't want that format for the output. I want to be able to standardize on whichever display is best for shiny, and use that across all of my data. That will also let me work out the input updates across the app one and use the same strategy everywhere, rather than having to sort it out across several different output formats.
Additional Comments
This is similar to #1820. We should probably discuss whether this is the approach we want to take for all of these.