Feature: Implement `strGroupSubset` in `Report_FlagOverTime()`

[jwildfire]

Feature Details

Filter table using same logic as Widget_GroupOverview. Ideally, we could use the same control in the report to trigger changes in both tables.

Example Code

Possible Implementation

Additional Comments

[jwildfire]

Might bump this to v2.1 depending on level of effort ...

[jonthegeek]

To confirm that this is what I think it is:

strGroupSubset should have possible values c("red", "amber", "red/amber")

• "red" = "only include cases with at least 1 red flag"
• "amber" = "only include cases with at least 1 amber flag"
• "red/amber" = "only include cases with at least 1 flag (either color)"

I could do that relatively easily on the R side... but doing so would prevent it from working on the javascript side (because I'd filter the data before it gets into the tool). But I could definitely imagine wanting non-interactive versions that do that filtering.

I think this is currently implemented as something somewhat in-between static (other places use kable) and interactive (other places use a direct htmlwidget or wrap gt in htmltools).

I feel like I can fix it, but I'm not certain which direction to take things.

[jwildfire]

Let's try creating a Widget_FlagOverTime() with strGroupSubset that interactively calls Report_FlagOverTime() based on the value of a via js that does the filter.

jonthegeek commented 1 month ago

@jwildfire I'm experimenting with linking the Widget_GroupOverview() <select> to Widget_FlagOverTime() (right now just in the developer console to work out how it will work), and it has raised another question. I think maybe Widget_FlagOverTime() should support more states than Widget_GroupOverview() (so it would normally have more values in its drop-down, but would update if a Widget_GroupOverview() on the same page):

• All
• 1+ flag (ever)
• 1+ flag (latest)
• 1+ red flag (ever)
• 1+ red flag (latest)
• 1+ amber flag (ever)
• 1+ amber flag (latest)

The "latest" values are equivalent to Widget_GroupOverview(), while "ever" would include rows that are currently green but were amber/red at some point in the past.

Does that sound right? It seemed weird that sites would show up in Widget_FlagOverTime() but not in Widget_GroupOverview() on a given page, but it also seems likely that a user would want to expand Widget_FlagOverTime() beyond what's currently possible in Widget_GroupOverview().

For now I'll probably avoid linking them together, but I'll try to implement this drop-down before Friday without the linkage.

jonthegeek commented 1 month ago

In theory, this should work! Now to actually implement it...

jwildfire commented 1 month ago

Yeah - I think that approach makes sense. Might be worth a quick chat with @samussiah to see how code was implemented in rbmviz and think about whether anything can be re-used in the widget.

jonthegeek commented 1 month ago

Hmm, should the filters be purely by site, like they are for Group Overview? Or should it filter by row in this? I feel like by row will be more natural when it's alone, but by site when Group Overview is on the same page. Although I guess the parameter is by Group, and we're grouping by Site, so in theory it should keep all the metrics for that site. I think I'll do it the same as Group Overview for now (except as noted above), and we can add a checkbox to show all metrics/only flagged metrics or something like that.

jwildfire commented 1 month ago

This filter should be by row - so by GroupID/MetricID combo.

samussiah commented 1 month ago

Yeah - I think that approach makes sense. Might be worth a quick chat with @samussiah to see how code was implemented in rbmviz and think about whether anything can be re-used in the widget.

rbm-viz has a basic update method that regenerates the table data when new dfSummary data are passed in. Initially all data are passed into the groupOverview widget and the subsetting is handled by addGroupSubset.

So both data structure and rendering are handled client side, whereas this module handles data structure "server" side with gt, if that makes any sense.

jonthegeek commented 1 month ago

Full thoughts on this (now that a lot of it is implemented in #1705):

• It would be nice to also have this parameter in the static Report_ function. There it would do the filtering once (in the data). This variable should NOT be passed from the Widget_ version to the Report_ version, though, because it prevents the drop-down from functioning properly.
• The drop-down is implemented in Widget_FlagOverTime(), but I don't yet allow you to set a starting value (via strGroupSubset).
• I definitely think it would be nice for Widget_GroupOverview() and Widget_FlagOverTime() to communicate via this drop-down, but it isn't 100% clear how that should work, since their drop-downs aren't perfectly overlapping. PROBABLY we'd want the "latest" version from Widget_FlagOverTime() to talk to Widget_GroupOverview(), but not the "ever" version, and we need to be careful to avoid update loops.

jwildfire commented 3 days ago

@jonthegeek Is basic functionality in the widget good to go? Can we go ahead and close this issue out and file a new issue for any additional tweaks/fixes?

jonthegeek commented 2 days ago

@jwildfire I think the basics are set. There's some decision-making to do to reduce dependencies (I think we should probably stick to either {gt} or {DT}, not both), but I'll go ahead and close this ticket!

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[jonthegeek]

@jwildfire I'm experimenting with linking the Widget_GroupOverview() <select> to Widget_FlagOverTime() (right now just in the developer console to work out how it will work), and it has raised another question. I think maybe Widget_FlagOverTime() should support more states than Widget_GroupOverview() (so it would normally have more values in its drop-down, but would update if a Widget_GroupOverview() on the same page):

• All
• 1+ flag (ever)
• 1+ flag (latest)
• 1+ red flag (ever)
• 1+ red flag (latest)
• 1+ amber flag (ever)
• 1+ amber flag (latest)

The "latest" values are equivalent to Widget_GroupOverview(), while "ever" would include rows that are currently green but were amber/red at some point in the past.

Does that sound right? It seemed weird that sites would show up in Widget_FlagOverTime() but not in Widget_GroupOverview() on a given page, but it also seems likely that a user would want to expand Widget_FlagOverTime() beyond what's currently possible in Widget_GroupOverview().

For now I'll probably avoid linking them together, but I'll try to implement this drop-down before Friday without the linkage.

[jonthegeek]

In theory, this should work! Now to actually implement it...

[jwildfire]

Yeah - I think that approach makes sense. Might be worth a quick chat with @samussiah to see how code was implemented in rbmviz and think about whether anything can be re-used in the widget.

[jonthegeek]

Hmm, should the filters be purely by site, like they are for Group Overview? Or should it filter by row in this? I feel like by row will be more natural when it's alone, but by site when Group Overview is on the same page. Although I guess the parameter is by Group, and we're grouping by Site, so in theory it should keep all the metrics for that site. I think I'll do it the same as Group Overview for now (except as noted above), and we can add a checkbox to show all metrics/only flagged metrics or something like that.

[jwildfire]

This filter should be by row - so by GroupID/MetricID combo.

[samussiah]

Yeah - I think that approach makes sense. Might be worth a quick chat with @samussiah to see how code was implemented in rbmviz and think about whether anything can be re-used in the widget.

rbm-viz has a basic update method that regenerates the table data when new dfSummary data are passed in. Initially all data are passed into the groupOverview widget and the subsetting is handled by addGroupSubset.

So both data structure and rendering are handled client side, whereas this module handles data structure "server" side with gt, if that makes any sense.

[jonthegeek]

Full thoughts on this (now that a lot of it is implemented in #1705):

• It would be nice to also have this parameter in the static Report_ function. There it would do the filtering once (in the data). This variable should NOT be passed from the Widget_ version to the Report_ version, though, because it prevents the drop-down from functioning properly.
• The drop-down is implemented in Widget_FlagOverTime(), but I don't yet allow you to set a starting value (via strGroupSubset).
• I definitely think it would be nice for Widget_GroupOverview() and Widget_FlagOverTime() to communicate via this drop-down, but it isn't 100% clear how that should work, since their drop-downs aren't perfectly overlapping. PROBABLY we'd want the "latest" version from Widget_FlagOverTime() to talk to Widget_GroupOverview(), but not the "ever" version, and we need to be careful to avoid update loops.

[jwildfire]

@jonthegeek Is basic functionality in the widget good to go? Can we go ahead and close this issue out and file a new issue for any additional tweaks/fixes?

[jonthegeek]

@jwildfire I think the basics are set. There's some decision-making to do to reduce dependencies (I think we should probably stick to either {gt} or {DT}, not both), but I'll go ahead and close this ticket!