Remove insertUI in the teal::init

[gogonzo]

Instead of waiting for DDL to load data and inserting Ui of the modules. Please make a reactive link between data and other modules and make a Data tab separately

Blocked by:

• Remove access to data from UI modules teal.slice#132
• [Bug]: Concept of delayed creates indirect dependency between data and UI elements teal.transform#111

[Polkas]

We have a long talk about the splash (data loading view) location and design.
We unanimously feel that the splash ui should not be inserted and removed in the DOM.
The idea presented by @gogonzo looks to be promising, and suited for NEST project.
It could work the same way as reporter previewer, the additional tab (first one) will be OPTIONALLY added only if needed i.e. the DDL is used.
@insightsengineering/nest-core-dev

[gogonzo]

Objective of the issue:

• keep DDL server and UI
• don't use removeUI and insertUI
• initialize FilteredData based on the reactive data coming from DDL
• initialize modules based on reactive filtered data
• Please provide POC for above

Later we can address:

• appereance of the UI

[gogonzo]

There is another an use case from @ianamovsesian which requires teal to be reactive on data input. The case looks as follows.

• user authorizes connection with remote data source. By providing Login, Password and clicking submit btn
• Once authorized study id can be chosen.
• Data is loaded when study is changed
• each time data changes, filter panel and modules need to be updated

[pawelru]

I like the above but please think about this a little bit wider and more general
I would rephrase / extend this into multi-stage, interactive data load. Each stage will be a module that returns boolean whether we can proceed to the next stage. Those will be executed one after another. We can think how to display them those: append or next screen or carousel? Yet another question mark is support of "back" action. Could be probably more but I hope you got the idea.
We can make a wrapper to build such module that requires specification of (i) inputs and (ii) condition returning boolean and obviously (iii) load logic.

I can imagine following scenario:
A) one stage - predefined file access

• requirements: login (textinput), pass (passinput)
• condition: logged user has read access to the predefined file
• logic: custom read file function

B) one stage - interactive data upload

• requirements: file (file input)
• condition: always true
• logic: read file function

C) two stage - interactive dir / file access
stage 1:
requirements: login (textinput) pass(passinput)
condition: logged user has read access to predefined dir
logic: none
stage 2:
requirements: file name (tree picker)
condition: always true
logic: read file function

D) multi stage db access to the table with value(s) in column(s) (e.g. select * from schema_id.study_data where study_id = ...)
stage 1:
requirements: login, pass, DB schema (pickerinput)
condition: logged user has read access
stage 2:
requirements: DB table (pickerinput)
condition: always true
stage 3:
requirements: column(s) name (pickerinput)
condition: always true
stage 4:
requirements: value(s) (pickerinput)
condition: always true

[gogonzo]

I can imagine following scenario:

@pawelru Yes, I consider described process as a single module which returns reactive data at the end. Number of stages and complexity of this module is not a concern - if teal could listen to the output change.

I can imagine following scenario:

I think we should provide flexibility to specify "DDL" module. This is solved by this proposition

[danielinteractive]

Just jumping in here - discussed with @pawelru on a use case that is coming up where a team would really benefit from an app where data can be uploaded, and teal modules exist for the analysis already.
Will be important to be flexible with the input data format here (e.g. some apps will require xlsx, some csv, etc.) and make this general enough (beyond e.g. ADaM data upload)

[gogonzo]

Closing this. It is now possible to call ui_teal and srv_teal directly and including teal in custom application. teal can now be a module!

simple app

options(
  teal.log_level = "TRACE",
  teal.show_js_log = TRUE,
  # teal.bs_theme = bslib::bs_theme(version = 5),
  shiny.bookmarkStore = "server"
)
library(scda)
pkgload::load_all("teal")
# pkgload::load_all("teal.slice")

ui_data <- function(id) {
  ns <- NS(id)
  tagList(
    actionButton(ns("submit"), label = "Submit to run")
  )
}

srv_data <- function(id, ...) {
  moduleServer(id, function(input, output, session) {
    eventReactive(input$submit, {
      data <- teal_data() |>
        within({
          logger::log_trace("Loading data")
          ADSL <- scda::synthetic_cdisc_data("latest")$adsl
          ADTTE <- scda::synthetic_cdisc_data("latest")$adtte
          iris <- iris
        })

      join_keys(data) <- default_cdisc_join_keys[c("ADSL", "ADTTE")]

      data
    })
  })
}

modules <- modules(
  teal.modules.general::tm_data_table("Data Table"),
  example_module("Example Module", datanames = "ADTTE"),
  module(
    ui = function(id) {
      ns <- NS(id)
      tagList(
        tableOutput(ns("filter_summary"))
      )
    },
    server = function(id, datasets) {
      moduleServer(id, function(input, output, session) {
        output$filter_summary <- renderTable({
          datasets$get_filter_overview(datanames = datasets$datanames())
        })
      })
    }
  )
)

shinyApp(
  ui = function(request) {
    fluidPage(
      ui_data("data"),
      ui_teal(id = "teal", modules = modules)
    )
  },
  server = function(input, output, session) {
    data_rv <- srv_data("data", data = data, modules = modules)
    srv_teal(id = "teal", data = data_rv, modules = modules)
  }
)

[m7pr]

Wow, this looks amazing. Great work!

[Polkas]

@gogonzo It is a fantastic piece of work.

[kpagacz]

Nicely done.