`clearSearch` sends multiple copies of the table to the client

Open
  • Is something wrong?
#1,149 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript, r
Domain
frontend, web-dev

Research direction

Start with inst/htmlwidgets/datatables.js at lines 1412-1429, where the issue reports that search updates trigger requests. Run the provided R and Shiny example and inspect the browser Network tab when clicking “clear search.” Done means clearing the search no longer sends duplicate identical table responses while preserving the expected clear-search behavior.

Written by the indexing model from the issue text.

Description

The clearSearch function appears to send multiple copies of the data table to the client. Here's a reproducible example. To see the issue, open up the inspector in your browser, go to the "Network" tab, and then click on the "clear search" button. You'll see all the requests come through. If you look at the responses, you'll notice that they are all identical (except for the "draw" property, which increments after each request).

library(DT)
library(shiny)

ui <- fluidPage(
  DT::dataTableOutput("table"),
  actionButton("clear_search", "clear search")
)

server <- function(input, output, session) {
  
  df <- do.call(rbind, lapply(1:1000, function(x) mtcars))

  output$table <- DT::renderDataTable(df, server = TRUE, filter = "top")
  
  observeEvent(input$clear_search, {
    dataTableProxy("table") |>
      clearSearch()
  })
}

shinyApp(ui, server)

Screenshot 2024-08-23 155344

The number of requests is equal to the number of columns plus one - my guess is one for each column plus the global search? This means that the more columns there are, the more duplicate copies there are. While in this case it doesn't cause much noticeable lag, it becomes an issue for very large datatables with lots of columns.

This issue also interacts with another issue: #504. That issue explains how the JSON object includes a vector that contains one element for each row, which makes the requests unnecessarily large for very large data tables. In my use case, the data table has over 870,000 rows and 32 columns. Each response ends up being 1.9MB because of the row numbers that are included in the JSON responses, and then this request is repeated 32 times, which means we're transferring a lot of unnecessary data every time the search is cleared.

I've done a bit of digging through the code, and this is the JavaScript code that's updating the search:

https://github.com/rstudio/DT/blob/4e63a4664d9caa9fb9d4fb17061ce5eab94bec18/inst/htmlwidgets/datatables.js#L1412C1-L1429C6

I'm assuming the problem lies in here somewhere?

Session info 
R version 4.4.1 (2024-06-14 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 22631), RStudio c(2024, 4, 2, 764)

Locale:
  LC_COLLATE=English_United States.utf8 
  LC_CTYPE=English_United States.utf8   
  LC_MONETARY=English_United States.utf8
  LC_NUMERIC=C                          
  LC_TIME=English_United States.utf8    

Package version:
  base64enc_0.1.3   bslib_0.8.0       cachem_1.1.0      cli_3.6.3        
  crosstalk_1.2.1   digest_0.6.36     DT_0.33.1         evaluate_0.24.0  
  fastmap_1.2.0     fontawesome_0.5.2 fs_1.6.4          glue_1.7.0       
  graphics_4.4.1    grDevices_4.4.1   highr_0.11        htmltools_0.5.8.1
  htmlwidgets_1.6.4 httpuv_1.6.15     jquerylib_0.1.4   jsonlite_1.8.8   
  knitr_1.48        later_1.3.2       lazyeval_0.2.2    lifecycle_1.0.4  
  magrittr_2.0.3    memoise_2.0.1     methods_4.4.1     mime_0.12        
  promises_1.3.0    R6_2.5.1          rappdirs_0.3.3    Rcpp_1.0.13      
  rlang_1.1.4       rmarkdown_2.28    sass_0.4.9        stats_4.4.1      
  tinytex_0.52      tools_4.4.1       utils_4.4.1       xfun_0.46        
  yaml_2.3.10

By filing an issue to this repo, I promise that

  • I have fully read the issue guide at https://yihui.org/issue/.
  • I have provided the necessary information about my issue.
    • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
    • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('DT'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('rstudio/DT').
    • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
  • I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

Dominant language
JavaScript
Stars
621
Forks
177
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rstudio/DT

All issues in rstudio/DT

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.