Implement Style functions for FilterState and Encoding Panel

[Polkas]

linked to insightsengineering/NEST-roadmap#11

Create two styling functions for FilterState and Encoding Panel.
Both functions will process a list to get a vector of human readable strings.

This is a part of our reporter UI: https://balsamiq.cloud/st5j94y/pkhl0a6/rB473

FilterState

# dput(get_filter_state(datasets))
# datasets is available e.g. in each of our modules
filter_state_raw <- list(ADSL = list(AGE = list(selected = c(20, 69), keep_na = FALSE, 
    keep_inf = FALSE), COUNTRY = list(selected = c("BRA", "PAK", 
"NGA", "RUS", "JPN", "GBR", "CAN"), keep_na = FALSE), ARM = list(
    selected = c("A: Drug X", "B: Placebo"), keep_na = FALSE), 
    TRTEDTM = list(selected = structure(c(1613603040, 1676686851.683
    ), class = c("POSIXct", "POSIXt"), tzone = ""), keep_na = TRUE), 
    EOSDY = list(selected = c(114, 731), keep_na = FALSE, keep_inf = FALSE)))

content like that have to be human readable after applying a new function (style_filter_state?).

e.g. Active Filter: (ADSL.AGE between 20 and 69) and (ADSL.ARM in ("A: Drug X", "B: Placebo")) and ...

SQL syntax might be a good idea. Be careful about different data types.

Encoding Panel

We want to process shiny input, e.g. name = value and name in (value1, value2). Some of inputs might be more complex.

Example of usage:

[nikolas-burkoff]

I can't help feeling the creation of the filter panel human readable state belongs in teal.slice:

• if you imagine adding a new dataset type (like we did with MAE) our current design involves updating teal.data to allow you to create it, teal.slice to embed the data object inside FilteredData and allow filtering, and then to update teal.reporter to create human readable info about of the filtering
• if we change the filter panel (e.g. to allow named filters to be used to pre-define a set of filters for a subgroup which you are going turn on and off, or to allow hierarchical filtering, or to allow factors to be dropped etc.) then we will need to update teal.reporter to work with these new cases rather than having get_human_readable_call(whatever_args) inside teal.slice or some other object which gets passed to reporter which has a print method

[kpagacz]

I am hesitant about adding anything regarding the encoding panel. Automatically getting all the shiny inputs will yield a lot of stuff that shouldn't make its way into a report. At the same time, the only other option is to make the module developer specify what goes in there, at which point we might as well not style it all and just let them use deparse1.

Mhm... Another idea. Prepare a function that takes ns("namespace") and the list of shiny inputs and their values. Then:

• filter out inputs that don't start with ns("namespace")
• remove ns("namespace") from what inputs are left
  That would leave us with id names without the pretending ns("namespace") and some values in the hopes that shiny ids are identifiable enough to be useful for people?

I don't feel good recommending such an option and market it as a human-readable shiny inputs...

[nikolas-burkoff]

So I believe that the encoding panel, its contents and what is transferred to the report is the responsibility of the module developer. But I think we should make things as easy as possible for them.

So for example we should create a human readable output for the data_extracts (or their replacement as it'll be really hacky to get them out at the moment as they are usually too embedded in with the merge - another reason to decouple them further @gogonzo) - and for any other complex custom UI we have created like arm_ref-comp_observer (or its replacement) - we could also make things easier by having something like add_component_to_card(label = "human_label", value = input$my_component) which deparses the value and adds the label onto it

Then I'm imagining

add_encoding_to_card(list(
  add_data_extract_spec_replacement(label = "foo", my_des()), # or input$my_des if it were a widget...
  add_component(label = "x", input$boo),
  ...
))     

or some such thing

and sub-shiny modules could pass stuff up if necessary (i.e. if there's a shiny module for some of the UI in the encoding panel whose values we need to capture)