New format of the filter states

[gogonzo]

@shajoezhu @lcd2yyz after refactor of the filter panel we removed "natural language formatting" of the filter states and they are all now printed in a technical way. Output you see here is the same for print(filter_states), save(filter_states) and for a TealReporter (used in tmc). There was a strong reason to change it as our classes were simply to complex and we needed to make some tradeoffs, and formatting was implemented in a way we shouldn't really release in the first time.
This "technical" print is fully repproducible and can be reused to restore filters - this is exact way in which we are going to store filters for bookmarking

Before	Now

Questions are:

• is it really matter how these filters are printed in the rapport as far are you fine with such filters output?
• If we limit number of printed fields is it okey to keep it in similar format (json)?

@chlebowa @m7pr @chlebowa @kartikeyakirar @donyunardi

[lcd2yyz]

The purpose of the reporter is to archive the data processing and analysis result, by ensure reproducibility for the input data and subsequently output. This is achieved with minimal fields/lines in the "before" version. Reporter is not meant to reproduce the state of the shiny app.

The "now" version has overwhelming amount of information. Many of the fields are needed for restoring filter settings or bookmarking, but not relevant for data processing to reproducing analysis results (eg. choices, fixed/locked, id). And json formatting looks too much like codes, not as "human-readable".

So I would prefer to still keep the current "before" version formatting of the reporter. I think we can apply more simplified formatting (eg. instead "selected value" or "selected range", simply use "selected" for all filter classes), but we should only display the selective fields that's most relevant for reproducible data processing.

For future discussion about saving/sharing filter states and/or app bookmarking, instead of json, we should also consider more concise formatting like yaml for better readability and accessibility.

[chlebowa]

"selected" may be misleading: does selected : 5, 6 mean "5 and 6" or "from 5 to 6"? One cannot know if the selection is a range unless one knows how many unique values there are in the data.

How about something like this?

[lcd2yyz]

This will be sufficient set of info.
But perhaps a bit more layman description will be nicer

Dataset name:
Variable name:
Selected values: (categorical separate by comma, range values with long dash)
Include NA values:
Include Inf values:

[gogonzo]

@lcd2yyz I'm preparing changes and so far it looks like this:

For data.frame

- Dataset name: ADSL
  Variable name: AGE
  Selected range: 20 - 69
- Dataset name: ADSL
  Variable name: RACE
  Selected values:
  - ASIAN
  - BLACK OR AFRICAN AMERICAN
  - WHITE
  - AMERICAN INDIAN OR ALASKA NATIVE
  - MULTIPLE
  - NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDER
  - OTHER
  - UNKNOWN
- Dataset name: ADSL
  Variable name: LSTALVDT
  Selected range: 2021-02-12 - 2023-03-03
  Include NA values: yes
- Dataset name: ADSL
  Variable name: study_duration_secs
  Selected values: '63113904'

For MAE

- Dataset name: MAE
  Applied expression: MAE$gender == "female"
- Dataset name: MAE
  Variable name: race
  Selected values:
  - asian
  - black or african american
  - white
  Include NA values: yes
- Dataset name: MAE
  Variable name: Protein
  Experiment: RPPAArray
  Filtering by: Genes
  Selected values:
  - ACVRL1
  - AR-R-V
  - ASNS-R-V

[lcd2yyz]

Overall looks good to me. Two minor comment/questions

1. I see there is a special handling for the "selected values" if there is 1 values vs multiple (in a list format).
   While the list format is easy to read/count, I don't see it as necessary. Special handling may give the user a feeling that "oh something is different", which is not the case here.
   Also, replicating analysis with the same filter condition will be easier if it's ready to be copy/paste, so I feel more programming-orientated users would actually prefer the vector format separated by comma, as we have before.
   Selected values: "ASIAN", "BLACK OR AFRICAN AMERICAN", "WHITE"

2. For "Include NA values", TRUE/FALSE value has been re-formatted to show "yes/no". I don't have strong objection against it, but I also don't see it as necessary. So if it helps to delete some formatting codes, feel free to just simply to show TRUE/FALSE directly.