Solution for modules-marketplace

[gogonzo]

• determine the optimal way to store the information about modules available for teal app creator
• make a prototype of function to return markeplace modules.
• (recommendation) store the information in the package
• It could be a manual, automatic or semi-automatic
• Don't depend on a namespaces and names convention - should be bulletproof

Suggestion:

teal.modules.clinical::available_modules() or something similar

[Polkas]

I do not agree with some assumptions where "Don't depend on a namespaces and names convention - should be bulletproof
" is most surprising for me.

so for example we using a naming convention in the pkgdown , so why not to use it for this purpose too.

  - title: General functionality modules
    contents:
      - matches('tm_[a-z][a-z]')
 
    - title: Modules for tables
    contents:
      - starts_with('tm_t_')

  - title: Modules for plots
    contents:
      - starts_with('tm_g_')
      - starts_with('tm_a_')

My idea is to use here the namespaces of each concern pacakge as I show before:

tmc_n <- asNamespace("teal.modules.clinical")

modules_names <- grep("tm_", ls(tmc_n), value = T)
tm_formals <- lapply(modules_names, function(x) formals(tmc_n[[x]]))
names(tm_formals) <- modules_names
tm_formals

[gogonzo]

@Polkas first step is less difficult to decide on searching namespace. As you noted above, we are pretty consistent with the naming but the problem will occur when we decide to distinguish end describe formals.
Imagine tm_g_xxx

tm_g_xxx:
  params:
    a: data_extract_spec
    b: character
    c: logical

In the latter stages of the design we will have to deduct what to pass to the module arguments. Dependency on the namespace doesn't give us any guarantee that we (our algorithm) will correctly guess the type of the argument. This is why we need to be explicit. It should be either some file with content of a function returning needed settings.

[Polkas]

if all modules arguments will have a default value then the problem is solved. For empty arguments we could use character(0)/integer(0) or sthing like data_extract_spec(NULL) (structure(list(), class = "")).

[Polkas]

Teal Wizard

The maintenance of the teal wizard connected data has to be as automatic as possible as this process will add another complexity layer to the project. This is another factor which will make the life more difficult for developers and mainly the newcomers.

As a developer I need to do x,y,z when adding new module or updating an existing one.
Number of these steps should be as little as possible.
The storage should be general and flexible for any extension.

Store perspective - local and global:

• local: store at the level of the specific repo like tmc. If we want to access this data after a package is build it has to be in the inst directory and not Rbuildignore-ed.
• global: store in the repo with the teal wizard.

Information:

What information we needed for each module:

• Title
• Description
• List of arguments and their types
• Default values for arguments*
• Image ?; how to define and do we really need it? a link to a gallery with photos or we could create a simple design images (thumbnail) from scratch. Creation of a proper images is a true graphical designer job.
• Support Reporter ; as an icon per module in the wizard
• Users Score (from 1 to 5); after some time will be helpful to e.g. sort the modules.
• Other

*I feel that we need much more here as this will be used to generated the html input of a certain type and possible values

Example of thumbnail image of a module:
Only for a reference do NOT use this website`s images on production
Please check how looks like the github marketplace thumbnails.

Maintenance:

How records are added/removed or updated

Functions:

• Create the yaml
• Validate the yaml - confront with the current state wherever it is possible
• Update the yaml - support multi-modules updates

Images of each module have to be created automatically

Representation:

Each module record should have enough information to build a proper marketplace card and HTML input for each of its arguments.

R6 class for each argument type with to_list/from_list/get_shiny_input methods.

Validation:

How to validate that we have all records with all proper information.

Automatic processing - Example:

tmc_n <- asNamespace("teal.modules.general")

modules_names <- grep("tm_", ls(tmc_n), value = T)
tm_formals <- lapply(modules_names, function(x) formals(tmc_n[[x]]))
names(tm_formals) <- modules_names

# Arguments Defaults
tm_formals_sc <- tm_formals$tm_g_scatterplot
tm_formals_sc
is_call <- vapply(tm_formals_sc, is.call, logical(1))
is_empty <- vapply(tm_formals_sc, function(x) identical(x, bquote()), logical(1))
is_name <- vapply(tm_formals_sc, is.name, logical(1)) & !is_empty
# types
c(
  lapply(lapply(tm_formals_sc[is_call | is_name], eval, envir = tmc_n), class),
  lapply(tm_formals_sc[is_empty], function(x) "empty"),
  lapply(tm_formals_sc[!(is_empty | is_call | is_name)], class)
)[names(tm_formals_sc)]


db <- tools::Rd_db("teal.modules.general")
sc <- db$tm_g_scatterplot.Rd
sc_names <- lapply(sc, attr, "Rd_tag")
names(sc) <- sc_names

# Title
sc[["\\title"]][[1]]
# Description
trimws(paste(unlist(sc[["\\description"]]), collapse = ""))

[Polkas]

@gogonzo nad @kumamiao I got an information that the current view on the teal wizard is much simplified. We will not give an option to specify the arguments from the wizard app perspective. As I understand sb is choosing modules and we give a template with already defined defaults. Thus from now on I assume such simplified scope.

[gogonzo]

@Polkas solution with browsing the documentation looks good. If we keep the information in the yaml files we can use your code for testing, to make sure that we keep this up to date. And yes, at this moment we will use simplified version for teal-skeleton but in the long term the solution should also cover addition of the arguments and so on.
I just noticed that shape of the marketplace is dependent on #58
we can pause this issue for a while.

[Polkas]

SHiny UI Editor
At the moment we could not use this technology as not assume to be reused by other projects.