[Feature Request]: Allow modules to use teal.picks

[osenan]

Feature description

With the creation of teal.picks repository modules can be refactored so they also use teal.picks. Here is a list of modules and related PRs:

module	assigne	PR
tm_g_events_term_id	@m7pr	#329
tm_g_ae_oview	@osenan	#331
tm_g_ae_sub	@llrs-roche	#332
tm_g_butterfly	@osenan	#335
tm_g_decorate
tm_g_heat_by_grade
tm_g_patient_profile
tm_g_spiderplot
tm_g_swimlane
tm_g_waterfall

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[llrs-roche]

It is scope creep but if possible when modifying the modules:

• Add decorators support (if possible).
• Add support for the new reporting features (server module should return the teal_report)

Happy not to do that but at least we should open an issue on the repository to tackle later on.

[osenan]

Something that came on first revision
When defining S3 method dispatch, should generic have default arguments defined? I think, and based on base R S3 generic, that no. Generics should have only arguments but default definition should be in the S3 methods. We should have coherent argument definition across all modules.

[osenan]

Also, we should have one single approach about using S3 methods or only supporting picks. Does not make sense to have some modules that allow for teal.transform and teal.picks and others that do not. I support the S3 dispatch.

[llrs-roche]

@osenan That was the goal from the beginning with the possible exception of teal.modules.clinical: insightsengineering/nestdevs-tasks#120