We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Examples of behavior that contributes to a positive environment for our community include:
Examples of unacceptable behavior include:
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [INSERT CONTACT METHOD]. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla’s code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
🙏 Thank you for taking the time to contribute!
Your input is deeply valued, whether an issue, a pull request, or even feedback, regardless of size, content or scope.
👶 Getting started
📔 Code of Conduct
🗃 License
Please refer the project documentation for a brief introduction. Please also see other articles within the project documentation for additional information.
A Code of Conduct governs this project. Participants and contributors are expected to follow the rules outlined therein.
All your contributions will be covered by this project’s license.
We use GitHub to track issues, feature requests, and bugs. Before submitting a new issue, please check if the issue has already been reported. If the issue already exists, please upvote the existing issue 👍.
For new feature requests, please elaborate on the context and the benefit the feature will have for users, developers, or other relevant personas.
This repository uses the GitHub Flow model for collaboration. To submit a pull request:
Create a branch
Please see the branch naming convention below. If you don’t have write access to this repository, please fork it.
Make changes
Make sure your code
Create a pull request (PR)
In the pull request description, please link the relevant issue (if any), provide a detailed description of the change, and include any assumptions.
Suppose your changes are related to a current issue in the current project; please name your branch as follows: <issue_id>_<short_description>. Please use underscore (_) as a delimiter for word separation. For example, 420_fix_ui_bug would be a suitable branch name if your change is resolving and UI-related bug reported in issue number 420 in the current project.
<issue_id>_<short_description>
_
420_fix_ui_bug
420
If your change affects multiple repositories, please name your branches as follows: <issue_id>_<issue_repo>_<short description>. For example, 69_awesomeproject_fix_spelling_error would reference issue 69 reported in project awesomeproject and aims to resolve one or more spelling errors in multiple (likely related) repositories.
<issue_id>_<issue_repo>_<short description>
69_awesomeproject_fix_spelling_error
69
awesomeproject
monorepo
staged.dependencies
Sometimes you might need to change upstream dependent package(s) to be able to submit a meaningful change. We are using staged.dependencies functionality to simulate a monorepo behavior. The dependency configuration is already specified in this project’s staged_dependencies.yaml file. You need to name the feature branches appropriately. This is the only exception from the branch naming convention described above.
staged_dependencies.yaml
Please refer to the staged.dependencies package documentation for more details.
This repository follows some unified processes and standards adopted by its maintainers to ensure software development is carried out consistently within teams and cohesively across other repositories.
This repository follows the standard tidyverse style guide and uses lintr for lint checks. Customized lint configurations are available in this repository’s .lintr file.
tidyverse
lintr
.lintr
Lightweight is the right weight. This repository follows tinyverse recommedations of limiting dependencies to minimum.
If the code is not compatible with all (!) historical versions of a given dependenct package, it is required to specify minimal version in the DESCRIPTION file. In particular: if the development version requires (imports) the development version of another package - it is required to put abc (>= 1.2.3.9000).
DESCRIPTION
abc (>= 1.2.3.9000)
We continuously test our packages against the newest R version along with the most recent dependencies from CRAN and BioConductor. We recommend that your working environment is also set up in the same way. You can find the details about the R version and packages used in the R CMD check GitHub Action execution log - there is a step that prints out the R sessionInfo().
R CMD check
sessionInfo()
If you discover bugs on older R versions or with an older set of dependencies, please create the relevant bug reports.
pre-commit
We highly recommend that you use the pre-commit tool combined with R hooks for pre-commit to execute some of the checks before committing and pushing your changes.
R hooks for pre-commit
Pre-commit hooks are already available in this repository’s .pre-commit-config.yaml file.
.pre-commit-config.yaml
As mentioned previously, all contributions are deeply valued and appreciated. While all contribution data is available as part of the repository insights, to recognize a significant contribution and hence add the contributor to the package authors list, the following rules are enforced:
git blame
*Excluding auto-generated code, including but not limited to roxygen comments or renv.lock files.
roxygen
renv.lock
The package maintainer also reserves the right to adjust the criteria to recognize contributions.
If you have further questions regarding the contribution guidelines, please contact the package/repository maintainer.
If you believe you have found a security vulnerability in any of the repositories in this organization, please report it to us through coordinated disclosure.
Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.
Instead, please send an email to vulnerability.management[@]roche.com.
Please include as much of the information listed below as you can to help us better understand and resolve the issue:
This information will help us triage your report more quickly.
Please make sure that while reporting issues in the form a bug, feature, or pull request, all sensitive information such as PII, PHI, and PCI is completely removed from any text and attachments, including pictures and videos.
The teal framework provides a large catalog of -plug-in-ready analysis modules to be incorporated into teal -applications. However, it is also possible to create your own modules -using the module function.
teal
module
In this guide, we will use the simple histogram below as an example, +and demonstrate how to convert this histogram function into a robust +teal module step-by-step:
+my_plot <- hist( + dataset[[vars]], + las = 1, + main = paste("Histogram of", vars), + xlab = vars, + col = "lightblue", + border = "black" +)
my_plot <- hist( + dataset[[vars]], + las = 1, + main = paste("Histogram of", vars), + xlab = vars, + col = "lightblue", + border = "black" +)
This module will allow users to dynamically select datasets and +variables to create histograms within a teal application. +We will cover best practices, including:
teal_data
This function contains the UI required for the module. It should be a -function with at least the argument id. See the server -section below for more details.
id
When developing a custom teal module for visualizations, +we will first identify the primary inputs that users will interact +with:
dataset
vars
These inputs are dynamically populated based on the available +datasets and variables in the teal_data object, which we +will cover later.
The UI function defines the controls and display area for the +histogram. For this module, we will use:
selectInput
plotOutput
verbatimTextOutput
Here’s the code for the histogram_module_ui +function:
histogram_module_ui
+# UI function for the custom histogram module +histogram_module_ui <- function(id) { + ns <- shiny::NS(id) + shiny::tagList( + shiny::selectInput(ns("dataset"), "Select Dataset", choices = NULL), + shiny::selectInput(ns("variable"), "Select Variable", choices = NULL), + shiny::plotOutput(ns("histogram_plot")), + shiny::verbatimTextOutput(ns("plot_code")) # To display the reactive plot code + ) +}
# UI function for the custom histogram module +histogram_module_ui <- function(id) { + ns <- shiny::NS(id) + shiny::tagList( + shiny::selectInput(ns("dataset"), "Select Dataset", choices = NULL), + shiny::selectInput(ns("variable"), "Select Variable", choices = NULL), + shiny::plotOutput(ns("histogram_plot")), + shiny::verbatimTextOutput(ns("plot_code")) # To display the reactive plot code + ) +}
The server function is where the main logic of a teal +module is handled. For our histogram module, the server function will +handle user interactions and manage the reactive teal_data +object, which allows the module to dynamically respond to user +inputs.
data
This function contains the shiny server logic for the -module and should be of the form:
shiny
-function( - id, - data, # optional; use if module needs access to application data - filter_panel_api, # optional; use if module needs access to filter panel; see teal.slice - reporter, # optional; use if module supports reporting; see reporting vignette - ...) { +To begin, it’s essential to include the data argument in +the server function definition. +This data argument holds the reactive +teal_data object, which contains your datasets and any +filters applied. By including data, we can ensure: + +The server function receives a reactive version of +teal_data, allowing it to automatically respond to +changes. +The server can access the filtered datasets directly. + +The correct function definition for the server function is: + +histogram_module_server <- function(id, data) { moduleServer(id, function(input, output, session) { - # module code here + # Server logic goes here }) } -The data that arrives in the module is a teal_data -object, the data container used throughout the teal -application. teal_data is passed to the init -function when building the application and, after filtering by the -filter panel, it is passed to modules, wrapped in a reactive expression. -The teal_data class allows modules to track the -R code that they execute so that module outputs can be -reproduced. See the teal.data package for a detailed -explanation. +If you need a refresher on the teal_data object, please +visit the teal.data +package documentation.
function( - id, - data, # optional; use if module needs access to application data - filter_panel_api, # optional; use if module needs access to filter panel; see teal.slice - reporter, # optional; use if module supports reporting; see reporting vignette - ...) { +To begin, it’s essential to include the data argument in +the server function definition. +This data argument holds the reactive +teal_data object, which contains your datasets and any +filters applied. By including data, we can ensure: + +The server function receives a reactive version of +teal_data, allowing it to automatically respond to +changes. +The server can access the filtered datasets directly. + +The correct function definition for the server function is: + +histogram_module_server <- function(id, data) { moduleServer(id, function(input, output, session) { - # module code here + # Server logic goes here }) } -The data that arrives in the module is a teal_data -object, the data container used throughout the teal -application. teal_data is passed to the init -function when building the application and, after filtering by the -filter panel, it is passed to modules, wrapped in a reactive expression. -The teal_data class allows modules to track the -R code that they execute so that module outputs can be -reproduced. See the teal.data package for a detailed -explanation. +If you need a refresher on the teal_data object, please +visit the teal.data +package documentation.
To begin, it’s essential to include the data argument in +the server function definition.
This data argument holds the reactive +teal_data object, which contains your datasets and any +filters applied. By including data, we can ensure:
The correct function definition for the server function is:
+histogram_module_server <- function(id, data) { moduleServer(id, function(input, output, session) { - # module code here + # Server logic goes here }) }
histogram_module_server <- function(id, data) { moduleServer(id, function(input, output, session) { - # module code here + # Server logic goes here }) }
The data that arrives in the module is a teal_data -object, the data container used throughout the teal -application. teal_data is passed to the init -function when building the application and, after filtering by the -filter panel, it is passed to modules, wrapped in a reactive expression. -The teal_data class allows modules to track the -R code that they execute so that module outputs can be -reproduced. See the teal.data package for a detailed -explanation.
init
R
teal.data
If you need a refresher on the teal_data object, please +visit the teal.data +package documentation.
When used in the server logic of a teal module, the +teal_data object becomes a reactive data +container. This means that to access its contents, you need to +call it like a function, using parentheses: data().
data()
This syntax triggers reactivity, ensuring that the data within +teal_data stays up-to-date with any filters or changes +applied elsewhere in the application.
+Note: The teal_data object behaves as a +reactive data container only when used within the server logic. If +accessed outside of the server, it will not be reactive. +
Note: The teal_data object behaves as a +reactive data container only when used within the server logic. If +accessed outside of the server, it will not be reactive.
names()
Here is a minimal module that allows the user to select and view one -dataset at a time. By default, filtering is enabled for all datasets. -Note that dataset choices are specified by the datanames -property of the teal_data container.
datanames
-library(teal) - -my_module <- function(label = "example teal module") { - checkmate::assert_string(label) - - module( - label = label, - server = function(id, data) { - moduleServer(id, function(input, output, session) { - updateSelectInput(session, "dataname", choices = isolate(names(data()))) - output$dataset <- renderPrint({ - req(input$dataname) - data()[[input$dataname]] - }) - }) - }, - ui = function(id) { - ns <- NS(id) - sidebarLayout( - sidebarPanel(selectInput(ns("dataname"), "Choose a dataset", choices = NULL)), - mainPanel(verbatimTextOutput(ns("dataset"))) - ) - } - ) -}
library(teal) - -my_module <- function(label = "example teal module") { - checkmate::assert_string(label) - - module( - label = label, - server = function(id, data) { - moduleServer(id, function(input, output, session) { - updateSelectInput(session, "dataname", choices = isolate(names(data()))) - output$dataset <- renderPrint({ - req(input$dataname) - data()[[input$dataname]] - }) - }) - }, - ui = function(id) { - ns <- NS(id) - sidebarLayout( - sidebarPanel(selectInput(ns("dataname"), "Choose a dataset", choices = NULL)), - mainPanel(verbatimTextOutput(ns("dataset"))) - ) - } - ) -}
The teal_data object can contain multiple datasets. To +retrieve the names of these datasets, use the names() +function:
+names(data())
names(data())
This will return a character vector of the dataset names contained in +teal_data. You can then use these names to dynamically +populate input controls, like a dataset selection drop-down.
[[ ]])
The example below allows the user to interact with the data to create -a simple visualization. In addition, it prints the code that can be used -to reproduce that visualization.
-library(teal) +To access an individual dataset from teal_data, use +double brackets ([[ ]]) along with the dataset name. This +allows you to extract the specific dataset as a data frame: + +data()[[input$dataset]] +Here, input$dataset represents the name of the dataset +selected by the user. This syntax is highly flexible because it +dynamically references whichever dataset the user has chosen. You can +further subset or manipulate this extracted data frame as needed. +
library(teal) +To access an individual dataset from teal_data, use +double brackets ([[ ]]) along with the dataset name. This +allows you to extract the specific dataset as a data frame: + +data()[[input$dataset]] +Here, input$dataset represents the name of the dataset +selected by the user. This syntax is highly flexible because it +dynamically references whichever dataset the user has chosen. You can +further subset or manipulate this extracted data frame as needed. +
To access an individual dataset from teal_data, use +double brackets ([[ ]]) along with the dataset name. This +allows you to extract the specific dataset as a data frame:
[[ ]]
+data()[[input$dataset]]
data()[[input$dataset]]
Here, input$dataset represents the name of the dataset +selected by the user. This syntax is highly flexible because it +dynamically references whichever dataset the user has chosen. You can +further subset or manipulate this extracted data frame as needed.
input$dataset
In this updated server function, we will perform the following:
new_data
within()
input$variable
renderPlot()
Here’s the code:
+# Server function for the custom histogram module with injected variables in within() +histogram_module_server <- function(id, data) { + moduleServer(id, function(input, output, session) { -# ui function for the module -# allows for selecting dataset and one of its numeric variables -ui_histogram_example <- function(id) { - ns <- NS(id) - sidebarLayout( - sidebarPanel( - selectInput(ns("datasets"), "select dataset", choices = NULL), - selectInput(ns("numerics"), "select numeric variable", choices = NULL) - ), - mainPanel( - plotOutput(ns("plot")), - verbatimTextOutput(ns("code")) - ), - ) -} + # Update dataset choices based on available datasets in teal_data + shiny::observe({ + shiny::updateSelectInput( + session, + "dataset", + choices = names(data()) + ) + }) -# server function for the module -# presents datasets and numeric variables for selection -# displays a histogram of the selected variable -# displays code to reproduce the histogram -srv_histogram_example <- function(id, data) { - moduleServer(id, function(input, output, session) { - # update dataset and variable choices - # each selection stored in separate reactive expression - updateSelectInput(inputId = "datasets", choices = isolate(names(data()))) - observe({ - req(dataset()) - nums <- vapply(data()[[dataset()]], is.numeric, logical(1L)) - updateSelectInput(inputId = "numerics", choices = names(nums[nums])) + # Update variable choices based on selected dataset, only including numeric variables + observeEvent(input$dataset, { + req(input$dataset) # Ensure dataset is selected + numeric_vars <- names(data()[[input$dataset]])[sapply(data()[[input$dataset]], is.numeric)] + shiny::updateSelectInput(session, "variable", choices = numeric_vars) }) - dataset <- reactive(input$datasets) - selected <- reactive(input$numerics) - # add plot code - plot_code_q <- reactive({ - validate(need(length(dataset()) == 1L, "Please select a dataset")) - validate(need(length(selected()) == 1L, "Please select a variable")) - req(selected() %in% names(data()[[dataset()]])) + # Create a reactive `teal_data` object with the histogram plot + result <- reactive({ + req(input$dataset, input$variable) # Ensure both dataset and variable are selected - # evaluate plotting expression within data - # inject input values into plotting expression - within( + # Create a new teal_data object with the histogram plot + new_data <- within( data(), - p <- hist(dataset[, selected], las = 1), - dataset = as.name(dataset()), selected = selected() + { + my_plot <- hist( + input_dataset[[input_vars]], + las = 1, + main = paste("Histogram of", input_vars), + xlab = input_vars, + col = "lightblue", + border = "black" + ) + }, + input_dataset = as.name(input$dataset), # Replace `input_dataset` with input$dataset + input_vars = input$variable # Replace `input_vars` with input$variable ) + new_data }) - # view plot - output$plot <- renderPlot({ - plot_code_q()[["p"]] + # Render the histogram from the updated teal_data object + output$histogram_plot <- shiny::renderPlot({ + result()[["my_plot"]] # Access and render the plot stored in `new_data` }) - # view code - output$code <- renderText({ - get_code(plot_code_q()) + # Reactive expression to get the generated code for the plot + output$plot_code <- shiny::renderText({ + teal.code::get_code(result()) # Retrieve and display the code for the updated `teal_data` object }) }) -} - -# function that creates module instance to use in `teal` app -tm_histogram_example <- function(label) { - module( +}
# Server function for the custom histogram module with injected variables in within() +histogram_module_server <- function(id, data) { + moduleServer(id, function(input, output, session) { -# ui function for the module -# allows for selecting dataset and one of its numeric variables -ui_histogram_example <- function(id) { - ns <- NS(id) - sidebarLayout( - sidebarPanel( - selectInput(ns("datasets"), "select dataset", choices = NULL), - selectInput(ns("numerics"), "select numeric variable", choices = NULL) - ), - mainPanel( - plotOutput(ns("plot")), - verbatimTextOutput(ns("code")) - ), - ) -} + # Update dataset choices based on available datasets in teal_data + shiny::observe({ + shiny::updateSelectInput( + session, + "dataset", + choices = names(data()) + ) + }) -# server function for the module -# presents datasets and numeric variables for selection -# displays a histogram of the selected variable -# displays code to reproduce the histogram -srv_histogram_example <- function(id, data) { - moduleServer(id, function(input, output, session) { - # update dataset and variable choices - # each selection stored in separate reactive expression - updateSelectInput(inputId = "datasets", choices = isolate(names(data()))) - observe({ - req(dataset()) - nums <- vapply(data()[[dataset()]], is.numeric, logical(1L)) - updateSelectInput(inputId = "numerics", choices = names(nums[nums])) + # Update variable choices based on selected dataset, only including numeric variables + observeEvent(input$dataset, { + req(input$dataset) # Ensure dataset is selected + numeric_vars <- names(data()[[input$dataset]])[sapply(data()[[input$dataset]], is.numeric)] + shiny::updateSelectInput(session, "variable", choices = numeric_vars) }) - dataset <- reactive(input$datasets) - selected <- reactive(input$numerics) - # add plot code - plot_code_q <- reactive({ - validate(need(length(dataset()) == 1L, "Please select a dataset")) - validate(need(length(selected()) == 1L, "Please select a variable")) - req(selected() %in% names(data()[[dataset()]])) + # Create a reactive `teal_data` object with the histogram plot + result <- reactive({ + req(input$dataset, input$variable) # Ensure both dataset and variable are selected - # evaluate plotting expression within data - # inject input values into plotting expression - within( + # Create a new teal_data object with the histogram plot + new_data <- within( data(), - p <- hist(dataset[, selected], las = 1), - dataset = as.name(dataset()), selected = selected() + { + my_plot <- hist( + input_dataset[[input_vars]], + las = 1, + main = paste("Histogram of", input_vars), + xlab = input_vars, + col = "lightblue", + border = "black" + ) + }, + input_dataset = as.name(input$dataset), # Replace `input_dataset` with input$dataset + input_vars = input$variable # Replace `input_vars` with input$variable ) + new_data }) - # view plot - output$plot <- renderPlot({ - plot_code_q()[["p"]] + # Render the histogram from the updated teal_data object + output$histogram_plot <- shiny::renderPlot({ + result()[["my_plot"]] # Access and render the plot stored in `new_data` }) - # view code - output$code <- renderText({ - get_code(plot_code_q()) + # Reactive expression to get the generated code for the plot + output$plot_code <- shiny::renderText({ + teal.code::get_code(result()) # Retrieve and display the code for the updated `teal_data` object }) }) -} - -# function that creates module instance to use in `teal` app -tm_histogram_example <- function(label) { - module( +}
Let’s review what we’ve done so far:
input_dataset = as.name(input$dataset)
input_dataset
input_vars = input$variable
input_vars
my_plot
output$histogram_plot
result()[["my_plot"]]
output$plot_code
teal.code::get_code(result())
The teal::module() function allows you to encapsulate +your UI and server logic into a teal module, making it +reusable and ready to integrate into any teal +application.
teal::module()
By setting datanames = "all", you give the module access +to all datasets specified in the teal_data object.
datanames = "all"
+# Custom histogram module creation +create_histogram_module <- function(label = "Histogram Module") { + teal::module( label = label, - server = srv_histogram_example, - ui = ui_histogram_example, + ui = histogram_module_ui, + server = histogram_module_server, datanames = "all" ) }
# Custom histogram module creation +create_histogram_module <- function(label = "Histogram Module") { + teal::module( label = label, - server = srv_histogram_example, - ui = ui_histogram_example, + ui = histogram_module_ui, + server = histogram_module_server, datanames = "all" ) }
This module is ready to be used in a teal app.
-app <- init( - data = teal_data(IRIS = iris, NPK = npk), - modules = tm_histogram_example(label = "Histogram Module"), - header = "Simple app with custom histogram module" -) - -if (interactive()) { - shinyApp(app$ui, app$server) -}
app <- init( - data = teal_data(IRIS = iris, NPK = npk), - modules = tm_histogram_example(label = "Histogram Module"), - header = "Simple app with custom histogram module" -) - -if (interactive()) { - shinyApp(app$ui, app$server) -}
Refer to this -vignette to read about adding support for reporting in your -teal module.
With the custom teal module set up, it can now be +integrated into a teal app. We’ll use init() +from teal to specify the datasets and modules used in the +app, then run the app to test the newly created module.
init()
+library(teal) + +# Define datasets in `teal_data` +data_obj <- teal_data( + iris = iris, + mtcars = mtcars +) + +# Initialize the teal app +app <- init( + data = data_obj, + modules = modules(create_histogram_module()) +) + +# Run the app +shiny::shinyApp(ui = app$ui, server = app$server)
library(teal) + +# Define datasets in `teal_data` +data_obj <- teal_data( + iris = iris, + mtcars = mtcars +) + +# Initialize the teal app +app <- init( + data = data_obj, + modules = modules(create_histogram_module()) +) + +# Run the app +shiny::shinyApp(ui = app$ui, server = app$server)
Congratulations! You just created a custom teal module and +used it in a teal app!
This setup provides a fully dynamic, user-controlled +teal module that allows for interactive data exploration +and code visibility, enhancing both usability and transparency.
Now that you’ve mastered the essentials of building and integrating +modules in teal, you’re ready to explore more advanced +features. teal offers a wide range of capabilities to +enhance your module’s functionality and user experience.
Enhance your custom teal module with reporting features! +Dive into this vignette +to see just how simple it is to add powerful reporting capabilities and +elevate your module’s impact.
The teal.widgets package provides various widgets which can be leveraged to quickly -create standard elements in your custom module.
teal.widgets
