[Feature Request]: Implement picks on modules

[averissimo]

Feature description

Overview

This issue tracks the refactoring of all tm_* modules to use teal.picks

Progress

Module	Assignee	PR	State
tm_a_gee	@osenan	#1508	DONE
tm_a_mmrm	@averissimo	#1498	DONE
tm_g_barchart_simple	@m7pr	#1512	waiting for CI/CD
tm_g_ci	@m7pr	#1513	DONE
tm_g_forest_rsp	@averissimo	#1516	DONE
tm_g_forest_tte	@averissimo	#1526	DONE
tm_g_ipp	@m7pr	#1523	DONE
tm_g_km	@m7pr	#1520	DONE
tm_g_lineplot	@m7pr	#1514	DONE
tm_g_pp_adverse_events	@averissimo	#1507	DONE
tm_g_pp_patient_timeline	@osenan	#1522	DONE
tm_g_pp_therapy	@osenan	#1524	DONE
tm_g_pp_vitals	@averissimo	#1505	DONE
tm_t_abnormality	@m7pr	#1487	DONE
tm_t_abnormality_by_worst_grade	@m7pr	#1488	DONE
tm_t_ancova	@averissimo	#1521	DONE
tm_t_binary_outcome	@m7pr	#1495	DONE
tm_t_coxreg	@m7pr	#1494	DONE
tm_t_events	@m7pr	#1484	DONE
tm_t_events_by_grade	@m7pr	#1493	DONE
tm_t_events_patyear	@m7pr	#1489	DONE
tm_t_events_summary	@m7pr	#1490	DONE
tm_t_exposure	@m7pr	#1491	DONE
tm_t_glm_counts	@m7pr	#1492	DONE
tm_t_logistic	@averissimo	#1501	DONE
tm_t_mult_events	@osenan	#1529	DONE
tm_t_pp_basic_info	@averissimo	#1502	DONE
tm_t_pp_laboratory	@averissimo	#1506	DONE
tm_t_pp_medical_history	@averissimo	#1503	DONE
tm_t_pp_prior_medication	@averissimo	#1504	DONE
tm_t_shift_by_arm	@m7pr	#1485	DONE
tm_t_shift_by_arm_by_worst	@m7pr	#1486	DONE
tm_t_shift_by_grade	@m7pr	#1480	DONE
tm_t_smq	@m7pr	#1481	DONE
tm_t_summary	@m7pr	#1479	DONE
tm_t_summary_by	@m7pr	#1482	DONE
tm_t_tte	@m7pr	#1483	DONE

---

To claim a module: add your GitHub handle in the Assignee column and link the corresponding PR or issue number in the PR/Issue column via a PR/comment edit.

[averissimo]

Guidelines:

S3 methods

Use dispatch to create S3 methods for data_extract_spec/choices_selected and picks/variables

Default arguments should be defined in methods, not the generic (insightsengineering/teal.osprey#331 (comment))

choices_selected()

Whenever data_extract_spec is not being used in module, convert arguments from choices_selected() -> variables()

arm_var <- teal.transform::choices_selected(c("ARM", "ARMCD"), "ARM")

arm_var_picks <- teal.picks::as.picks(arm_var)
arm_var_picks
#> <variables>
#>   choices: ARM, ARMCD
#>   selected: ARM
#>   multiple=FALSE, fixed=FALSE, allow-clear=FALSE

[averissimo]

I tried several prompt variations, and the most effective approach was to defer creating the S3 dispatch. Instead, the agent should focus solely on implementing the function that will eventually be used by the dispatch.

The tm_t_logistics_picks was used as template as it's a bit complex (but not too much):

• Source https://github.com/insightsengineering/teal.modules.clinical/blob/picks_averissimo/R/tm_t_logistic_picks.R
• It performs a merge of multiple datasets with several selectors
• Validates data using teal:::validate_input
• Uses raw input ids
• Uses anl_inputs and adsl_inputs (pattern in many modules)

Sample Prompt

Please convert the `tm_t_pp_basic_info.R` module to `teal.picks`  from `choices_selected` specification.

You can use the `tm_t_logistics.R` and `tm_t_logistics_picks.R` to understand what needs to be modified.

Here's a list that is not exaustive:

- `ui_t_basic_info` function should have explicit arguments
- `tm_t_pp_basic_info`module server:
  -  should set `ui_args` as a subset of formals
  - `teal.picks::picks()` should be created in the module from specification in arguments
  - convert the arguments if needed from `choices_selected` to `teal.picks::variables` and `teal.picks::values`
- `srv_t_basic_info` function:
  - use a specification of selectors from `teal.picks::picks_srv`
  - merge the selectors using `teal.picks::merge_srv` to create anl datasets (may only need 1)
  - validate the dataset using `teal:::validate_input` instead of {shinyvalidate} package

Create 2 new files in a "sandbox" folder and generate sample `teal` apps to run both the original module as well as the converted module

[m7pr]

Extended prompt

Please convert the `X.R` module to `teal.picks`  from `choices_selected` specification. Work on a new feature branche.

You can use PRs where other modules were rewritten, to understand what needs to be changed, like this one
https://github.com/insightsengineering/teal.modules.clinical/pull/1473

You can have a look at 
- this migration plan https://github.com/insightsengineering/nestdevs-tasks/issues/120
- this migration guideline https://github.com/insightsengineering/teal.modules.clinical/issues/1472#issuecomment-4054277630

If you can't open github in browser, you can use github cli to pull information

Potential list of changes, but not exhaustive:


- `ui_t_basic_info` function should have explicit arguments
- `tm_t_pp_basic_info`module server:
  -  should set `ui_args` as a subset of formals
  - `teal.picks::picks()` should be created in the module from specification in arguments
  - convert the arguments if needed from `choices_selected` to `teal.picks::variables` and `teal.picks::values`
- `srv_t_basic_info` function:
  - use a specification of selectors from `teal.picks::picks_srv`
  - merge the selectors using `teal.picks::merge_srv` to create anl datasets (may only need 1)
  - validate the dataset using `teal:::validate_input` instead of {shinyvalidate} package

Lastly, create git worktree for the new feature branch and old main branch, so that  you can compare sample `teal` apps
 on both implementations. Create scripts to test this module UI and run those apps, and make print screens and 
use browser to verify there are no obvious issues. Remember to update tests and shinytests and to run 
devtools::test() once you are done.