-
-
Notifications
You must be signed in to change notification settings - Fork 47
Open
Labels
Description
(please note that the below is just a rough design - feel free to adapt if needed)
module_validate_xyz()
- a shiny module executing validation:srv_validate_xyz(x)
- it does the following:check_1 <- module_check_foo(x, ...) check_2 <- module_check_bar(x, ...) check_3 <- module_check_baz(x, ...) ... checks <- list(check_1, check_2, check_3, ...) r_validate <- reactive({ for (check in checks) { validate(need(check()$isEmpty(), check$getMessages())) } x() }) output$errors <- renderUI({ r_validate() NULL }) x
ui_validate_xyz()
- display error message:tagList( uiOutput(NS(id, "errors")) )
- we might assign a dedicated CSS class and apply custom styling of that element.
- The goal is to allow nesting calls of validate module from another validate module
module_check_xyz()
- a shiny module executing checks:srv_module_check_xyz()
- returns reactive with theAssertCollection
object (see: https://mllg.github.io/checkmate/reference/AssertCollection.html)ui_module_check_xyz()
- empty fun (we can even don't create it at all)
check_xyz()
- for custom checks - only if needed, function returning TRUE if ok else error message (similar tocheckmate
)test_xyz()
- for custom checks - only if needed, function returning boolean (similar tocheckmate
)
Extra:
I do expect quite a few module_check_xyz()
functions, e.g. module_check_reactive()
, module_check_tryerror()
, module_check_shinysilenterror()
, module_check_qenverror
. Instead of exporting a lot of objects, we might create a factory to create them dynamically if needed. (or both?)
The goals it to have a functionality that is:
- testable
- extendable - e.g. one validate module calling another validate module
- returning consistent validation errors
The use cases:
teal:::srv_validate_reactive_teal_data
- teal modules (I assume this is going to be exported)