Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: Should decorator show error from upstream teal_data (pre-decorated) in the UI? #1421

Open
averissimo opened this issue Nov 21, 2024 · 6 comments
Labels
core question Further information is requested

Comments

@averissimo
Copy link
Contributor

          Do we want to have an error showing in the decorator's UI?

Using the example without X and Y

We might want to add a custom wrapper on srv_teal_transform_data that will return the original data if that has an error.

image

Originally posted by @averissimo in insightsengineering/teal.modules.general#797 (comment)

@averissimo averissimo changed the title Q: Should decorator show error from (pre-decorated) upstream teal_data in the UI? Q: Should decorator show error from upstream teal_data _(pre-decorated)_ in the UI? Nov 21, 2024
@averissimo averissimo changed the title Q: Should decorator show error from upstream teal_data _(pre-decorated)_ in the UI? Q: Should decorator show error from upstream teal_data (pre-decorated) in the UI? Nov 21, 2024
@m7pr m7pr added question Further information is requested core labels Nov 21, 2024
@averissimo
Copy link
Contributor Author

On the application below, we see a problem in Adverse Effects, which has errors coming from the encoding panel, but those are being shown in the decorator

library(teal)

decorator <- teal_transform_module(
  label = "Head",
  ui = function(id) shiny::checkboxInput(shiny::NS(id, "head_check"), "Show only first 6?", value = FALSE),
  server = make_teal_transform_server(
    quote({
      if (isTRUE(head_check)) iris <- head(iris, 6)
    })
  )
)

# Example below
init(
  data = teal_data() |> within(iris <- iris),
  modules = module(
    label = "Sample module",
    ui = function(id, decorators, ns = shiny::NS(id)) {
      shiny::tagList(
        shiny::tags$h4("🔵 Input with default encoding error"),
        shiny::checkboxInput(ns("check_me"), "Simulate error in data", FALSE),
        shiny::tags$h4("Decorator:"),
        ui_transform_teal_data(ns("decorator"), transformators = list(decorator)),
        shiny::tags$hr(),
        shiny::tags$h4("Output:"),
        shiny::verbatimTextOutput(ns("text"))
      )
    },
    server = function(id, data, decorators) {
      moduleServer(id, function(input, output, session) {
        table_q <- reactive({
          if (isTRUE(input$check_me)) {
            data
          } else {
            within(data, stop("Corrupted qenv with encoding error"))
          }
        })
        
        decorated_data <- srv_transform_teal_data("decorator", table_q, transformators = decorators)
        
        output$text <- shiny::renderPrint({
          req(table_q())
          decorated_data()[["iris"]]
        })
      })
    },
    ui_args = list(decorators = list(decorator)),
    server_args = list(decorators = list(decorator))
  )
) |> shiny::runApp()

@averissimo
Copy link
Contributor Author

A possible solution:

  • Add a parameter to teal_transform_teal_data that prevents transformators from executing
    • Defaults to current behavior

@donyunardi donyunardi added this to the Decorate modules' output milestone Dec 16, 2024
@donyunardi
Copy link
Contributor

Is this not related to the discussion that we have here?

And the conclusion was

This is what we will do to handle the errors:

  1. We will display the error on the first transform failure with the error message that causes this error.
  2. The subsequent transforms will not run because an error occurred in the upstream transformation and show a generic error message.
  3. When this error happens, we will completely hide this module's output and display an error message instead of the output.

Doesn't this mean the issue that's being raised here is as designed?

@m7pr
Copy link
Contributor

m7pr commented Jan 16, 2025

@donyunardi I think this is a bit different this time, please check @averissimo example from the opening of this issue

@kumamiao
Copy link

It's a bit different, but similar to the teal_transform_module discussion. I feel like the overall principle should be - we report error at the very first step when an error occurs, so that the user can trace back to where the issue is. To me the screenshot from the issue looks fine on where we have error messages, are we talking about making the error message under transform module more clear here?

@m7pr
Copy link
Contributor

m7pr commented Jan 21, 2025

@kumamiao error appeared on an Encoding Panel, since one of the inputs is missing. Error message got propagated to the decorator UI. The question is, should we show an error in decorator UI or not, if the error comes from Encoding Panel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants